Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

Sorry all me again.

I've written a program that picks up UDP broadcast packets containing
audio from a number of sources, mixes it together and presents it to
alsa for playback.

I'm experiencing random freezes.  I cant reproduce then running the
process under strace as the process on the ARM board slows down to the
point it underruns with ALSA all the time and the symptom doesn't show.

If I attach strace after the process has frozen I get this and nothing
else:

# strace -p 443
Process 443 attached - interrupt to quit
futex(0x4030e144, FUTEX_WAIT_PRIVATE, 2, NULL


This stop happens at random at any point typically after minutes but run
time can be over an hour.

I need to work around this as I need the board for a demo.

Im using, alsa-lib-1.0.25
kernel 2.6.36.4
BusyBox v1.19.2

I also compiled strace for arm, but this and a busybox shell is the only
environment I have on the board.

The problem showed when I starting using this function to poll alsa:

The same code on my PC dual core AMD does not seem to suffer the
problem  : alsa-lib-1.0.23, Linux jonspc 2.6.32.26-175.fc12.i686 #1 SMP

Before anyone points it out I want to poll as alsa is not the only sound
output supported by the code.

int sound_system_needs_data_now()
{
        int framesleft;
        snd_pcm_status_t *status;
        snd_pcm_status_alloca( &status );

        // If the alsa playback has stalled then it definately needs data
        snd_pcm_status(playback_handle,status);
        if( snd_pcm_status_get_state( status ) != SND_PCM_STATE_RUNNING )
                return(TRUE);

        framesleft=snd_pcm_avail (playback_handle);
	//printf("FL=%d\n",framesleft); fflush(stdout);

        if (framesleft>1000)
                return(TRUE);
        else
                return(FALSE);
}


Stuck process

# cat /proc/443/status 
Name:   udp-many-way-au
State:  S (sleeping)
Tgid:   443
Pid:    443
PPid:   392
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 32
Groups: 
VmPeak:     4356 kB
VmSize:     4292 kB
VmLck:       132 kB
VmHWM:      1788 kB
VmRSS:      1788 kB
VmData:      396 kB
VmStk:       136 kB
VmExe:        28 kB
VmLib:      3348 kB
VmPTE:        12 kB
VmSwap:        0 kB
Threads:        1
SigQ:   0/471
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000002000
SigIgn: 0000000000000006
SigCgt: 0000000180002000
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed:   1
Cpus_allowed_list:      0
Mems_allowed:   1
Mems_allowed_list:      0
voluntary_ctxt_switches:        5908
nonvoluntary_ctxt_switches:     1766


Any useful suggestions welcome.

Thanks,
Jon

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

Reposting this:

# strace -p 443
> Process 443 attached - interrupt to quit
> futex(0x4030e144, FUTEX_WAIT_PRIVATE, 2, NULL
> 
locks up.  Stops, stalls ... fails to continue ....


Now tried several alsa-lib versions.  A clue would be nice?
What do I replace to fix this ?

Anyone ?


Thanks,
Jon



On Thu, 2012-02-16 at 12:01 +0000, Jonathan Andrews wrote:
> Sorry all me again.
> 
> I've written a program that picks up UDP broadcast packets containing
> audio from a number of sources, mixes it together and presents it to
> alsa for playback.
> 
> I'm experiencing random freezes.  I cant reproduce then running the
> process under strace as the process on the ARM board slows down to the
> point it underruns with ALSA all the time and the symptom doesn't show.
> 
> If I attach strace after the process has frozen I get this and nothing
> else:
> 
> # strace -p 443
> Process 443 attached - interrupt to quit
> futex(0x4030e144, FUTEX_WAIT_PRIVATE, 2, NULL
> 
> 
> This stop happens at random at any point typically after minutes but run
> time can be over an hour.
> 
> I need to work around this as I need the board for a demo.
> 
> Im using, alsa-lib-1.0.25
> kernel 2.6.36.4
> BusyBox v1.19.2
> 
> I also compiled strace for arm, but this and a busybox shell is the only
> environment I have on the board.
> 
> The problem showed when I starting using this function to poll alsa:
> 
> The same code on my PC dual core AMD does not seem to suffer the
> problem  : alsa-lib-1.0.23, Linux jonspc 2.6.32.26-175.fc12.i686 #1 SMP
> 
> Before anyone points it out I want to poll as alsa is not the only sound
> output supported by the code.
> 
> int sound_system_needs_data_now()
> {
>         int framesleft;
>         snd_pcm_status_t *status;
>         snd_pcm_status_alloca( &status );
> 
>         // If the alsa playback has stalled then it definately needs data
>         snd_pcm_status(playback_handle,status);
>         if( snd_pcm_status_get_state( status ) != SND_PCM_STATE_RUNNING )
>                 return(TRUE);
> 
>         framesleft=snd_pcm_avail (playback_handle);
> 	//printf("FL=%d\n",framesleft); fflush(stdout);
> 
>         if (framesleft>1000)
>                 return(TRUE);
>         else
>                 return(FALSE);
> }
> 
> 
> Stuck process
> 
> # cat /proc/443/status 
> Name:   udp-many-way-au
> State:  S (sleeping)
> Tgid:   443
> Pid:    443
> PPid:   392
> TracerPid:      0
> Uid:    0       0       0       0
> Gid:    0       0       0       0
> FDSize: 32
> Groups: 
> VmPeak:     4356 kB
> VmSize:     4292 kB
> VmLck:       132 kB
> VmHWM:      1788 kB
> VmRSS:      1788 kB
> VmData:      396 kB
> VmStk:       136 kB
> VmExe:        28 kB
> VmLib:      3348 kB
> VmPTE:        12 kB
> VmSwap:        0 kB
> Threads:        1
> SigQ:   0/471
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: 0000000000002000
> SigIgn: 0000000000000006
> SigCgt: 0000000180002000
> CapInh: 0000000000000000
> CapPrm: ffffffffffffffff
> CapEff: ffffffffffffffff
> CapBnd: ffffffffffffffff
> Cpus_allowed:   1
> Cpus_allowed_list:      0
> Mems_allowed:   1
> Mems_allowed_list:      0
> voluntary_ctxt_switches:        5908
> nonvoluntary_ctxt_switches:     1766
> 
> 
> Any useful suggestions welcome.
> 
> Thanks,
> Jon
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

On Fri, 2012-02-17 at 21:04 +0000, Jonathan Andrews wrote:
> Reposting this:
> 
> # strace -p 443
> > Process 443 attached - interrupt to quit
> > futex(0x4030e144, FUTEX_WAIT_PRIVATE, 2, NULL
> > 
> locks up.  Stops, stalls ... fails to continue ....
> 
> 
> Now tried several alsa-lib versions.  A clue would be nice?
> What do I replace to fix this ?
> 
Now tried 2 kernels, 3 versions of alsalib still stalls.

If I remove alsa code it works forever.

Thanks to everyone who helped (no one at all).

FUCK OPEN SOURCE !!!!!!!!!!!

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Clemens Ladisch]

Jonathan Andrews wrote:
> On Fri, 2012-02-17 at 21:04 +0000, Jonathan Andrews wrote:
>> # strace -p 443
>>> futex(0x4030e144, FUTEX_WAIT_PRIVATE, 2, NULL
>>
>> locks up.  Stops, stalls ... fails to continue ....
>>
>> Now tried several alsa-lib versions.  A clue would be nice?
>> What do I replace to fix this ?
>>
> Now tried 2 kernels, 3 versions of alsalib still stalls.

The synchronization calls in alsa-lib shouldn't block unless you're
actually using several threads, and even then you wouldn't be able
to reproduce it so reliably.

Do you have a stack trace to find out where this is called from?

Can you confirm that pthread mutexes work on your board?


Regards,
Clemens

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Clemens Ladisch]

Jonathan Andrews wrote:
> I've tried building alsalib in many ways, at the moment its :
> $ ./configure --target=arm-linux --host=i686-linux --enable-shared --disable-static --without-pthread

Try adding --disable-ucm and --disable-python.


Regards,
Clemens

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Clemens Ladisch]

Jonathan Andrews wrote:
> On Mon, 2012-02-20 at 08:54 +0100, Clemens Ladisch wrote:
>> Jonathan Andrews wrote:
>>> I've tried building alsalib in many ways, at the moment its :
>>> $ ./configure --target=arm-linux --host=i686-linux --enable-shared --disable-static --without-pthread
>>
>> Try adding --disable-ucm and --disable-python.
>
> Err ok, alsa-lib still builds ok.

Now it doesn't use any pthread functions.

> My application runs for longer, but still freezes in the end. With the
> same futex locking problem.

I'd guess that this is not an alsa-lib problem.
Now you really need a stack trace.


Regards,
Clemens

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Clemens Ladisch]

Jonathan Andrews wrote:
> On Wed, 2012-02-22 at 17:23 +0100, Clemens Ladisch wrote:
>> Now it doesn't use any pthread functions.
>
> Thanks, use or require ? Still complains if I static compile my
> application but don't link with pthreads.

Please try with the patch below; this should remove the last
occurence of pthreads in alsa-lib.


Regards,
Clemens


--- alsa-lib/configure.in
+++ alsa-lib/configure.in
@@ -512,6 +512,7 @@ if test "$HAVE_LIBDL" != "yes"; then
 fi

 if test "$HAVE_LIBPTHREAD" != "yes"; then
+  build_pcm_meter="no"
   build_pcm_share="no"
 fi

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Clemens Ladisch]

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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

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
~                                                 

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Clemens Ladisch]

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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Takashi Iwai]

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. 
> 
> 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 ?

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 :-(
> 
> 2)  "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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

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. 
> > 
> > 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 ?
> 
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 :-(
> > 
> > 2)  "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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Clemens Ladisch]

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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

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

Re: Random process lockup on ARM board: alsa-lib-1.0.25, FUTEX_WAIT_PRIVATE

[Jonathan Andrews]

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