[alsa-devel] Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE
jon at jonshouse.co.uk
Thu Mar 8 22:42:16 CET 2012
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
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
> > 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.
> (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 ......
More information about the Alsa-devel