GNOME Bugzilla – Bug 129709
esound segfaults while use old version of alsa pcm api
Last modified: 2004-12-22 21:47:04 UTC
I'm using esound 0.2.32 (it isn't listed on version choose list in bugzilla, so I've choosen most recent), there is new alsa pcm api up from 1.0.0.pre1. esound compiles properly (with 2 warnings about conversion from int to int *) , but (as expected) segfaults while using new functions (which needs int * parameters) with old params (int). here is patch for it: --- ../esound-0.2.32.orig/audio_alsa09.c Thu Mar 20 09:34:19 2003 +++ ./audio_alsa09.c Sat Dec 20 03:01:11 2003 @@ -136,15 +136,17 @@ alsaerr = -1; return handle; } - - err = snd_pcm_hw_params_set_rate_near(handle, hwparams, speed, 0); + + int t_dir=0; + int t_speed=speed; + err = snd_pcm_hw_params_set_rate_near(handle, hwparams, &t_speed, &t_dir); if (err < 0) { if (alsadbg) fprintf(stderr, "%s\n", snd_strerror(err)); alsaerr = -1; return handle; } - if (err != speed) { + if (t_speed != speed) { if (alsadbg) fprintf(stderr, "Rate not avaliable %i != %i\n", speed, err); alsaerr = -1; @@ -176,8 +178,9 @@ alsaerr = -1; return handle; } - - err = snd_pcm_hw_params_set_buffer_size_near(handle, hwparams, BUFFERSIZE); + + snd_pcm_uframes_t t_bufsize=BUFFERSIZE; + err = snd_pcm_hw_params_set_buffer_size_near(handle, hwparams, &t_bufsize); if (err < 0) { if (alsadbg) fprintf(stderr, "Buffersize:%s\n", snd_strerror(err)); (BTW, there could be some kind of 'add file' option in gnome bugzilla)
Created attachment 22585 [details] [review] new alsa api patch
Adding the PATCH keyword. Fredric? :)
*** Bug 130012 has been marked as a duplicate of this bug. ***
Thanks for the patch, but we need to add some test in configure.in to allow use of esound with older version of alsa.
I'm not familiar with autoconf/automake, so I cannot apply patch to it, but I think that patch is clear and one should know what to change.
At what version does the ALSA API change? (trying to make autoconf-automake patch) -Eddy
I'm not sure, but based on the cvs page ( http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/src/pcm/pcm.c ) I think that api change was at 0.9.6->1.0.0pre1 maHo
After digging in ALSA's CVS, the functions started using pointers from pcm.c revision 1.220 (0.9.0_rc4?). I think it makes sense to patch audio_alsa09.c altogether, since these new functions started to appear in 0.9.0_rc4, which is very early in 0.9.x. So... I guess we can do it in 2 ways: 1. Change audio_alsa09.c altogether. 2. Use an autoconf macro to test these functions. I'll try to do option 2, since £ukasz had done option 1... :p -Eddy
Created attachment 23190 [details] [review] Patch for acconfig.h. Need to run autoheader to propagate change to config.h.
Created attachment 23191 [details] [review] Patch for configure.in. Need to run autoconf to propagate changes to configure script.
Created attachment 23192 [details] [review] Modified patch for audio_alsa09.c
The previous 3 patches enables the configure script to correctly detect system's settings. I have the configure script to try to link one of the (offending) function. When tested in my kernel-2.6.0-gentoo-r1 system, config.log shows: configure:7818: gcc -o conftest -g -O2 conftest.c 1>&5 configure: In function `main': configure:7813: warning: passing arg 3 of `snd_pcm_hw_params_set_rate_near' makes pointer from integer without a cast configure:7813: warning: passing arg 4 of `snd_pcm_hw_params_set_rate_near' makes pointer from integer without a cast /tmp/ccu3LO0K.o(.text+0x19): In function `main': /home/eddy/lab/esdPelennor/configure:7813: undefined reference to `snd_pcm_hw_params_set_rate_near' collect2: ld returned 1 exit status This causes DRIVER_ALSA_09_AFTER_RC4 to be #defined. When the source audio_alsa09.c is preprocessed, then the correct parameters are passed. (I don't know how to coalesce all 3 files into a patch file... sorry. This is my first Bugzilla "effort", too. So I'll be happy if someone can give me pointers to "the right way of doing it"). :p -Eddy
Created attachment 23193 [details] [review] revised patch for configure.in. Patch against original configure.in (esound 0.2.32).
Description about attachment 29193 [details] [review]: Oops. Just realized some mistake. First, I decided to put the AC_TRY_LINK after "-lasound" is already in ${LIBS}. Secondly, I decided to append "-Werror" to CFLAGS, to treat warnings as errors (because it causes segfaults in esound). If I didn't, apparently the macro AC_TRY_LINK still perceive the warnings as a succesful compile, and ended up not #define-ing DRIVER_ALSA_09_AFTER_RC4. -Eddy
I've committed all your patches, somehow fixed :)