Re: [alsa-devel] Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE
Jonathan Andrews wrote:
On Thu, 2012-03-08 at 10:55 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
I'm using this script to build both static and dynamic versions of the alsalib. Can you check the configure arguments are correct.
They look correct.
Tried to compile my application, still fails asking for pthreads.
The configure.in file contains the patch, but the generated configure script does not have it (although its time stamp is newer). Please ensure that you've run autoconf (although make should do this automatically).
Regards, Clemens
On Thu, 2012-03-08 at 12:43 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
On Thu, 2012-03-08 at 10:55 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
I'm using this script to build both static and dynamic versions of the alsalib. Can you check the configure arguments are correct.
They look correct.
Tried to compile my application, still fails asking for pthreads.
The configure.in file contains the patch, but the generated configure script does not have it (although its time stamp is newer). Please ensure that you've run autoconf (although make should do this automatically).
Regards, Clemens
aclocal.m4:16: warning: this file was generated for autoconf 2.68. You have another version of autoconf. It may work, but is not guaranteed to. If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'. configure.in:15: error: Autoconf version 2.62 or higher is required aclocal.m4:6823: AM_INIT_AUTOMAKE is expanded from... configure.in:15: the top level autom4te: /usr/bin/m4 failed with exit status: 63
Thanks for finding that, seems its a version problem. My machine has version 2.61
Upgrading now.
Thanks, Jon
On Thu, 2012-03-08 at 12:43 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
On Thu, 2012-03-08 at 10:55 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
I'm using this script to build both static and dynamic versions of the alsalib. Can you check the configure arguments are correct.
They look correct.
Tried to compile my application, still fails asking for pthreads.
The configure.in file contains the patch, but the generated configure script does not have it (although its time stamp is newer). Please ensure that you've run autoconf (although make should do this automatically).
Getting closer, alsalib now builds without the need for pthreads but seems to insist on dlopen dlclose even in static lib ?
Compiling udp-many-way-audio-rx.c -> udp-many-way-audio-rx_alsa_arms (static) /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(pcm_dshare.o): In function `snd_pcm_dshare_sync_ptr': pcm_dshare.c:(.text+0x6a4): warning: Warning: snd_pcm_hwsync() is deprecated, consider to use snd_pcm_avail() /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(pcm_direct.o): In function `snd1_pcm_direct_parse_open_conf': pcm_direct.c:(.text+0x58c8): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(pcm_shm.o): In function `_snd_pcm_shm_open': pcm_shm.c:(.text+0x27dc): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(dlmisc.o): In function `snd_dlopen': dlmisc.c:(.text+0x38): undefined reference to `dlopen' /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(dlmisc.o): In function `snd_dlclose': dlmisc.c:(.text+0x90): undefined reference to `dlclose' /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(dlmisc.o): In function `snd_dlsym_verify': dlmisc.c:(.text+0x190): undefined reference to `dlsym' /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(dlmisc.o): In function `snd_dlsym': dlmisc.c:(.text+0x2f8): undefined reference to `dlsym' /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(pcm_ladspa.o): In function `snd_pcm_ladspa_free_plugins': pcm_ladspa.c:(.text+0x3cc): undefined reference to `dlclose' /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/libasound.a(pcm_ladspa.o): In function `snd_pcm_ladspa_check_file': pcm_ladspa.c:(.text+0x41c4): undefined reference to `dlopen' pcm_ladspa.c:(.text+0x41e4): undefined reference to `dlsym' pcm_ladspa.c:(.text+0x4250): undefined reference to `dlclose' pcm_ladspa.c:(.text+0x4344): undefined reference to `dlclose' pcm_ladspa.c:(.text+0x43b0): undefined reference to `dlclose' collect2: ld returned 1 exit status ~
Jonathan Andrews wrote:
Getting closer, alsalib now builds without the need for pthreads but seems to insist on dlopen dlclose even in static lib ?
Add --without-libdl.
Regards, Clemens
On Thu, 2012-03-08 at 15:35 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
Getting closer, alsalib now builds without the need for pthreads but seems to insist on dlopen dlclose even in static lib ?
Add --without-libdl.
Ok, that fixed it thanks.
A couple of comments.
1) A lot of my trouble was this : configure.in:15: error: Autoconf version 2.62 or higher is required
If autoconf exists, is executed, but does not complete should configure not exit with an error ?
I checked the output of the configure/make carefully. Autoconf was silently failing, gives no clues at all. As the datetime is in the binary created each library had a unique file hash so I (reasonably) assumed it to be doing the job :-(
2) "Add --without-libdl", ok ... should "--static" not turn this on then ?
Thanks, Jon
At Thu, 08 Mar 2012 15:14:50 +0000, Jonathan Andrews wrote:
On Thu, 2012-03-08 at 15:35 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
Getting closer, alsalib now builds without the need for pthreads but seems to insist on dlopen dlclose even in static lib ?
Add --without-libdl.
Ok, that fixed it thanks.
A couple of comments.
- A lot of my trouble was this :
configure.in:15: error: Autoconf version 2.62 or higher is required
If autoconf exists, is executed, but does not complete should configure not exit with an error ?
Blame your autoconf :)
I checked the output of the configure/make carefully. Autoconf was silently failing, gives no clues at all. As the datetime is in the binary created each library had a unique file hash so I (reasonably) assumed it to be doing the job :-(
- "Add --without-libdl", ok ... should "--static" not turn this on then ?
dlopen() can be still used for taking other objects like LADSPA or external io or pcm plugins. There is no reason to prohibit dlopen() in a static library.
Takashi
On Thu, 2012-03-08 at 16:34 +0100, Takashi Iwai wrote:
At Thu, 08 Mar 2012 15:14:50 +0000, Jonathan Andrews wrote:
On Thu, 2012-03-08 at 15:35 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
Getting closer, alsalib now builds without the need for pthreads but seems to insist on dlopen dlclose even in static lib ?
Add --without-libdl.
Ok, that fixed it thanks.
A couple of comments.
- A lot of my trouble was this :
configure.in:15: error: Autoconf version 2.62 or higher is required
If autoconf exists, is executed, but does not complete should configure not exit with an error ?
Blame your autoconf :) Hmmmm .... true, but still not convinced this could not have been prevented by reading the errorlevel and crapping out with a nice fluffy error message for me !
I checked the output of the configure/make carefully. Autoconf was silently failing, gives no clues at all. As the datetime is in the binary created each library had a unique file hash so I (reasonably) assumed it to be doing the job :-(
- "Add --without-libdl", ok ... should "--static" not turn this on then ?
dlopen() can be still used for taking other objects like LADSPA or external io or pcm plugins. There is no reason to prohibit dlopen() in a static library.
Ok, makes sense.
Thanks, Jon
On Thu, 2012-03-08 at 16:34 +0100, Takashi Iwai wrote:
At Thu, 08 Mar 2012 15:14:50 +0000, Jonathan Andrews wrote:
On Thu, 2012-03-08 at 15:35 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
Getting closer, alsalib now builds without the need for pthreads but seems to insist on dlopen dlclose even in static lib ?
Add --without-libdl.
Using the static libasound without pthreads now.
Process still stalls in same way:
ARM / # strace -p 408 Process 408 attached - interrupt to quit futex(0x15a684, FUTEX_WAIT, 2, NULL ^C <unfinished ...> Process 408 detached
Took 3 hours 1 min to stall. It was decoding 8 udp audio streams, a second tx process reading from the same sound device was also running.
An strace of a stall (intel this time) is here. Its 2GB and on a slow link (sorry). http://www.jonshouse.co.uk/download/a_stop.txt
futex(0xae5320, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted) --- SIGINT (Interrupt) @ 0 (0) ---
The futex address 0xae5320 occurs only once at the end of the text file so I have no idea what sets it up.
Thanks, Jon
Jonathan Andrews wrote:
Using the static libasound without pthreads now.
Process still stalls in same way:
ARM / # strace -p 408 Process 408 attached - interrupt to quit futex(0x15a684, FUTEX_WAIT, 2, NULL
So it's not a call from alsa-lib.
An strace of a stall (intel this time) is here. Its 2GB and on a slow link (sorry). http://www.jonshouse.co.uk/download/a_stop.txt
If only there were a tool to compress files ...
The futex address 0xae5320 occurs only once at the end of the text file so I have no idea what sets it up.
Can't you attach gdb to your process? Or at least log where in your program you are? (If strace has too much overhead, write to a variable, and run a thread that waits for keyboard input and prints the variable.)
Regards, Clemens
On Thu, 2012-03-08 at 21:40 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
Using the static libasound without pthreads now.
Process still stalls in same way:
ARM / # strace -p 408 Process 408 attached - interrupt to quit futex(0x15a684, FUTEX_WAIT, 2, NULL
So it's not a call from alsa-lib.
The alsa code is a conditional compile, as is that for the /dev/dsp device. Only the alsa version fails, the version that just takes data from the network and mixes it does not fail.
cc udp-many-way-audio-rx.c -DARM -DALSA -lasound -lrt -lm -o udp-many-way-audio-rx_alsa_arms --static Fails randomly
cc udp-many-way-audio-rx.c -DARM -DDUMMY -DSTATIC -o udp-many-way-audio-rx_dummy_arms --static Dummy version, never fails. Still has network code and my audio mixer.
Its not as if I'm linking in a lot of libs...
An strace of a stall (intel this time) is here. Its 2GB and on a slow link (sorry). http://www.jonshouse.co.uk/download/a_stop.txt
If only there were a tool to compress files ...
Ok, i'm pretty tired I admit it .... 30MB http://www.jonshouse.co.uk/download/a_stop.txt.gz
The futex address 0xae5320 occurs only once at the end of the text file so I have no idea what sets it up.
Can't you attach gdb to your process?
I need to build an arm version, will work on that next.
Or at least log where in your program you are?
I did that, best I can tell it enters one of these two functions but never exists. Makes sense as these are the two conditional compiles wrapped around #ifdef ALSA in the main loop. http://www.jonshouse.co.uk/download/udp-many-way-audio-playsample-alsa.c
(If strace has too much overhead, write to a variable, and run a thread that waits for keyboard input and prints the variable.)
The strace (now gzipped) is the same process as the arm running (and then stalling) on the PC. It still stalls, just takes (on average) longer to stall on the faster machine ......
Thanks, Jon
Just to finish this thread.
Maybe its not an alsa bug, but only happens to my code when using alsa.
Report filed here. http://sourceware.org/bugzilla/show_bug.cgi?id=13845
Thanks, Jon
participants (3)
-
Clemens Ladisch -
Jonathan Andrews -
Takashi Iwai