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

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

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
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Reposting this:

# strace -p 443

Quoted 3 lines

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 ?

Quoted 8 lines · Jonathan Andrews

# strace -p 443

Quoted 1 line

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.

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

Quoted 5 lines · Clemens Ladisch

Quoted 2 lines · Jonathan Andrews

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.

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

Using kernel 3.2.5 with alsa-lib 1.0.25, all compiled with generic Debian arm-linux-gnueabi toolchain.

arm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2 Was used to build kernel, alsa-lib and application.

Changing gcc version, kernel version or alsa-lib version makes the problem worse or better, but ALL versions seem to suffer this problem. I have also seen it once on Intel (but only once so far).

Something seeks broken at a lower layer than im using.  I simply don't have the skill to debug it.

The hardware is a USB cm109 audio adapter, but the problem seems to show on more than this one driver.

The audio application writing to alsa will freezes at random intervals, infrequent at the moment, last one was after runtime 20H 37M 29S.  Two processes are running, one reading from the sound device and one writing to the sound device. I am not using threading or anything very clever just generic alsa functions.

This is the only diagnostic I can generate so far as running the application under strace slows it to the point it no longer functions enough to generate the problem.

ARM / # strace -p 417
Process 417 attached - interrupt to quit futex(0x175734, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...> Process 417 detached

ARM / # uname -a
Linux (none) 3.2.5 #2 Wed Feb 22 17:11:52 GMT 2012 armv4tl GNU/Linux ARM / # uptime
 22:36:19 up 22:36,  0 users,  load average: 0.15, 0.16, 0.18 ARM / # cat /proc/cpuinfo
Processor       : ARM920T rev 0 (v4l)
BogoMIPS        : 199.06
Features        : swp half thumb crunch
CPU implementer : 0x41
CPU architecture: 4T
CPU variant     : 0x1
CPU part        : 0x920
CPU revision    : 0

Any help welcome.

Thanks,
Jon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi ,

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

BR
Huang Shijie

Quoted 52 lines · Jonathan Andrews

Using kernel 3.2.5 with alsa-lib 1.0.25, all compiled with generic Debian arm-linux-gnueabi toolchain.

arm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2 Was used to build kernel, alsa-lib and application.

Changing gcc version, kernel version or alsa-lib version makes the problem worse or better, but ALL versions seem to suffer this problem. I have also seen it once on Intel (but only once so far).

Something seeks broken at a lower layer than im using. I simply don't have the skill to debug it.

The hardware is a USB cm109 audio adapter, but the problem seems to show on more than this one driver.

The audio application writing to alsa will freezes at random intervals, infrequent at the moment, last one was after runtime 20H 37M 29S. Two processes are running, one reading from the sound device and one writing to the sound device. I am not using threading or anything very clever just generic alsa functions.

This is the only diagnostic I can generate so far as running the application under strace slows it to the point it no longer functions enough to generate the problem.

ARM / # strace -p 417
Process 417 attached - interrupt to quit futex(0x175734, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...> Process 417 detached

ARM / # uname -a
Linux (none) 3.2.5 #2 Wed Feb 22 17:11:52 GMT 2012 armv4tl GNU/Linux ARM / # uptime
22:36:19 up 22:36, 0 users, load average: 0.15, 0.16, 0.18
ARM / # cat /proc/cpuinfo
Processor : ARM920T rev 0 (v4l)
BogoMIPS : 199.06
Features : swp half thumb crunch
CPU implementer : 0x41
CPU architecture: 4T
CPU variant : 0x1
CPU part : 0x920
CPU revision : 0

Any help welcome.

Thanks,
Jon

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 5 lines · Huang Shijie

Hi ,

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

Are either of you able to bisect the kernel?

At the very least can you
find two kernels where it works and where it does not?

Hanging on FUTEX_WAIT_PRIVATE can be the symptom for higher level problems including userspace locking issues and race conditions.

Quoted 9 lines · Darren Hart

Quoted 5 lines · Huang Shijie

Hi ,

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

Are either of you able to bisect the kernel?

I'm not a kernel hacker what do you mean ?

Quoted 6 lines

At the very least can you
find two kernels where it works and where it does not?

Hanging on FUTEX_WAIT_PRIVATE can be the symptom for higher level problems including userspace locking issues and race conditions.

My workload is UDP network audio. I have compiled my code with and without ALSA support. The version without ALSA seems to run forever, the version with ALSA works on ARM for between a few minutes and a few hours. On Intel the same futex stall problem occurs, but it may take runtime of days.

I have two processes running. One RX process that takes UDP packets from the network mixes them and presents them to ALSA as an audio stream, the second process takes audio from the sound device and transmits it as a UDP audio stream. The two processes are independent.

My workload is atypical as I need to both transmit and receive audio via UDP on a 27/7 basis.

So far I have experienced the problem on 3 kernels, but I have tried only 3 kernels it may be all 2.6 kernels that suffer.

My development PC is "Linux jonspc 2.6.32.26-175.fc12.i686 #1 SMP Wed Dec 1 21:52:04 UTC 2010 i686 athlon i386 GNU/Linux"

My ARM board target:
ARM / # uname -a
Linux (none) 3.2.5 #2 Wed Feb 22 17:11:52 GMT 2012 armv4tl GNU/Linux

And my ARM target running its older kernel was (2.6.36).

I have an strace of the process running and stalling on the PC. The file is 2GB, its not a fast link sorry.

http://www.jonshouse.co.uk/download/a_stop.txt

Many thanks,
Jon

Quoted 5 lines · Huang Shijie

Hi ,

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

Are either of you able to bisect the kernel? At the very least can you

find two kernels where it works and where it does not?

Hanging on FUTEX_WAIT_PRIVATE can be the symptom for higher level problems including userspace locking issues and race conditions.

Huang, are you also on ARM?

--
Darren

Quoted 62 lines

BR
Huang Shijie

Quoted 52 lines · Jonathan Andrews

Using kernel 3.2.5 with alsa-lib 1.0.25, all compiled with generic Debian arm-linux-gnueabi toolchain.

arm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2 Was used to build kernel, alsa-lib and application.

Changing gcc version, kernel version or alsa-lib version makes the problem worse or better, but ALL versions seem to suffer this problem. I have also seen it once on Intel (but only once so far).

Something seeks broken at a lower layer than im using.  I simply don't have the skill to debug it.

The hardware is a USB cm109 audio adapter, but the problem seems to show on more than this one driver.

The audio application writing to alsa will freezes at random intervals, infrequent at the moment, last one was after runtime 20H 37M 29S.  Two processes are running, one reading from the sound device and one writing to the sound device. I am not using threading or anything very clever just generic alsa functions.

This is the only diagnostic I can generate so far as running the application under strace slows it to the point it no longer functions enough to generate the problem.

ARM / # strace -p 417
Process 417 attached - interrupt to quit futex(0x175734, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...> Process 417 detached

ARM / # uname -a
Linux (none) 3.2.5 #2 Wed Feb 22 17:11:52 GMT 2012 armv4tl GNU/Linux ARM / # uptime
 22:36:19 up 22:36,  0 users,  load average: 0.15, 0.16, 0.18 ARM / # cat /proc/cpuinfo
Processor       : ARM920T rev 0 (v4l)
BogoMIPS        : 199.06
Features        : swp half thumb crunch
CPU implementer : 0x41
CPU architecture: 4T
CPU variant     : 0x1
CPU part        : 0x920
CPU revision    : 0

Any help welcome.

Thanks,
Jon

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Hi,

Quoted 5 lines · Darren Hart

Quoted 2 lines · Huang Shijie

Hi ,

Quoted 5 lines

Quoted 3 lines

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

Are either of you able to bisect the kernel? At the very least can you

I finially found my arch/arm/include/asm/futex.h is not the latest, so i updated the header.

And the futex issue is gone now. But a dataAbort issue appears, I am not sure whether it caused by the futex patch.
I am debugging it now.

BR
Huang Shijie

Quoted 6 lines

find two kernels where it works and where it does not?

Hanging on FUTEX_WAIT_PRIVATE can be the symptom for higher level problems including userspace locking issues and race conditions.

Huang, are you also on ARM?

Yes, FREESCALE imx6q platform.

BR
Huang Shijie

Quoted 76 lines

--
Darren

Quoted 62 lines

BR
Huang Shijie

Quoted 52 lines · Jonathan Andrews

Using kernel 3.2.5 with alsa-lib 1.0.25, all compiled with generic Debian arm-linux-gnueabi toolchain.

arm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2 Was used to build kernel, alsa-lib and application.

Changing gcc version, kernel version or alsa-lib version makes the problem worse or better, but ALL versions seem to suffer this problem. I have also seen it once on Intel (but only once so far).

Something seeks broken at a lower layer than im using. I simply don't have the skill to debug it.

The hardware is a USB cm109 audio adapter, but the problem seems to show on more than this one driver.

The audio application writing to alsa will freezes at random intervals, infrequent at the moment, last one was after runtime 20H 37M 29S. Two processes are running, one reading from the sound device and one writing to the sound device. I am not using threading or anything very clever just generic alsa functions.

This is the only diagnostic I can generate so far as running the application under strace slows it to the point it no longer functions enough to generate the problem.

ARM / # strace -p 417
Process 417 attached - interrupt to quit futex(0x175734, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...> Process 417 detached

ARM / # uname -a
Linux (none) 3.2.5 #2 Wed Feb 22 17:11:52 GMT 2012 armv4tl GNU/Linux ARM / # uptime
22:36:19 up 22:36, 0 users, load average: 0.15, 0.16, 0.18
ARM / # cat /proc/cpuinfo
Processor : ARM920T rev 0 (v4l)
BogoMIPS : 199.06
Features : swp half thumb crunch
CPU implementer : 0x41
CPU architecture: 4T
CPU variant : 0x1
CPU part : 0x920
CPU revision : 0

Any help welcome.

Thanks,
Jon

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Quoted 8 lines · Huang Shijie

Hi,

Quoted 5 lines · Darren Hart

Quoted 2 lines · Huang Shijie

Hi ,

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

Are either of you able to bisect the kernel? At the very least can you

I finially found my arch/arm/include/asm/futex.h is not the latest, so i updated the header.

Just make sure it matches your kernel version.

Quoted 4 lines

And the futex issue is gone now. But a dataAbort issue appears, I am not sure whether it caused by the futex patch.
I am debugging it now.

Which APIs are you using that make the futex syscall?

--
Darren

Quoted 9 lines

BR
Huang Shijie

Quoted 5 lines

find two kernels where it works and where it does not?

Hanging on FUTEX_WAIT_PRIVATE can be the symptom for higher level problems including userspace locking issues and race conditions.

Quoted 82 lines

Quoted 1 line

Huang, are you also on ARM?

Yes, FREESCALE imx6q platform.

BR
Huang Shijie

Quoted 76 lines

--
Darren

Quoted 62 lines

BR
Huang Shijie

Quoted 52 lines · Jonathan Andrews

Using kernel 3.2.5 with alsa-lib 1.0.25, all compiled with generic Debian arm-linux-gnueabi toolchain.

arm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2 Was used to build kernel, alsa-lib and application.

Changing gcc version, kernel version or alsa-lib version makes the problem worse or better, but ALL versions seem to suffer this problem. I have also seen it once on Intel (but only once so far).

Something seeks broken at a lower layer than im using.  I simply don't have the skill to debug it.

The hardware is a USB cm109 audio adapter, but the problem seems to show on more than this one driver.

The audio application writing to alsa will freezes at random intervals, infrequent at the moment, last one was after runtime 20H 37M 29S.  Two processes are running, one reading from the sound device and one writing to the sound device. I am not using threading or anything very clever just generic alsa functions.

This is the only diagnostic I can generate so far as running the application under strace slows it to the point it no longer functions enough to generate the problem.

ARM / # strace -p 417
Process 417 attached - interrupt to quit futex(0x175734, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...> Process 417 detached

ARM / # uname -a
Linux (none) 3.2.5 #2 Wed Feb 22 17:11:52 GMT 2012 armv4tl GNU/Linux ARM / # uptime
 22:36:19 up 22:36,  0 users,  load average: 0.15, 0.16, 0.18 ARM / # cat /proc/cpuinfo
Processor       : ARM920T rev 0 (v4l)
BogoMIPS        : 199.06
Features        : swp half thumb crunch
CPU implementer : 0x41
CPU architecture: 4T
CPU variant     : 0x1
CPU part        : 0x920
CPU revision    : 0

Any help welcome.

Thanks,
Jon

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

hi,

Quoted 23 lines · Darren Hart

Quoted 8 lines · Huang Shijie

Hi,

Quoted 5 lines · Darren Hart

Quoted 2 lines · Huang Shijie

Hi ,

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

Are either of you able to bisect the kernel? At the very least can you

I finially found my arch/arm/include/asm/futex.h is not the latest, so i updated the header.

Just make sure it matches your kernel version.

Quoted 1 line

Quoted 6 lines

Quoted 3 lines

And the futex issue is gone now. But a dataAbort issue appears, I am not sure whether it caused by the futex patch.
I am debugging it now.

Which APIs are you using that make the futex syscall?

futex_wait().

I cherry-pick the
" df77abc ARM: 7099/1: futex: preserve oldval in SMP __futex_atomic_op" to the arch/arm/include/asm/futex.h.

BR
Huang Shijie

Quoted 99 lines

--
Darren

Quoted 9 lines

BR
Huang Shijie

Quoted 5 lines

find two kernels where it works and where it does not?

Hanging on FUTEX_WAIT_PRIVATE can be the symptom for higher level problems including userspace locking issues and race conditions.

Quoted 82 lines

Quoted 1 line

Huang, are you also on ARM?

Yes, FREESCALE imx6q platform.

BR
Huang Shijie

Quoted 76 lines

--
Darren

Quoted 62 lines

BR
Huang Shijie

Quoted 52 lines · Jonathan Andrews

Using kernel 3.2.5 with alsa-lib 1.0.25, all compiled with generic Debian arm-linux-gnueabi toolchain.

arm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2 Was used to build kernel, alsa-lib and application.

Changing gcc version, kernel version or alsa-lib version makes the problem worse or better, but ALL versions seem to suffer this problem. I have also seen it once on Intel (but only once so far).

Something seeks broken at a lower layer than im using. I simply don't have the skill to debug it.

The hardware is a USB cm109 audio adapter, but the problem seems to show on more than this one driver.

The audio application writing to alsa will freezes at random intervals, infrequent at the moment, last one was after runtime 20H 37M 29S. Two processes are running, one reading from the sound device and one writing to the sound device. I am not using threading or anything very clever just generic alsa functions.

This is the only diagnostic I can generate so far as running the application under strace slows it to the point it no longer functions enough to generate the problem.

ARM / # strace -p 417
Process 417 attached - interrupt to quit futex(0x175734, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...> Process 417 detached

ARM / # uname -a
Linux (none) 3.2.5 #2 Wed Feb 22 17:11:52 GMT 2012 armv4tl GNU/Linux ARM / # uptime
22:36:19 up 22:36, 0 users, load average: 0.15, 0.16, 0.18
ARM / # cat /proc/cpuinfo
Processor : ARM920T rev 0 (v4l)
BogoMIPS : 199.06
Features : swp half thumb crunch
CPU implementer : 0x41
CPU architecture: 4T
CPU variant : 0x1
CPU part : 0x920
CPU revision : 0

Any help welcome.

Thanks,
Jon

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Quoted 30 lines · Huang Shijie

hi,

Quoted 27 lines · Darren Hart

Quoted 8 lines · Huang Shijie

Hi,

Quoted 5 lines · Darren Hart

Quoted 2 lines · Huang Shijie

Hi ,

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

I meet a similar problem with the latest futex code.

I play the video and the processes will hang at the futex.

Are either of you able to bisect the kernel? At the very least can you

I finially found my arch/arm/include/asm/futex.h is not the latest, so i updated the header.

Just make sure it matches your kernel version.

Quoted 4 lines

And the futex issue is gone now. But a dataAbort issue appears, I am not sure whether it caused by the futex patch.
I am debugging it now.

Quoted 4 lines

Quoted 2 lines

Which APIs are you using that make the futex syscall?

futex_wait().

You are calling the futex syscall directly from your application?

Quoted 1 line · Clemens Ladisch

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.

Quoted 5 lines · Clemens Ladisch

Quoted 2 lines · Jonathan Andrews

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.

Quoted 8 lines · Jonathan Andrews

Quoted 5 lines · Clemens Ladisch

Quoted 2 lines · Jonathan Andrews

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

Quoted 5 lines · Jonathan Andrews

Quoted 4 lines · Clemens Ladisch

Quoted 2 lines · Jonathan Andrews

I'm using this script to build both static and dynamic versions of the alsalib. Can you check the configure arguments are correct.

Quoted 3 lines

Quoted 1 line

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 ?

Quoted 2 lines · Jonathan Andrews

Getting closer, alsalib now builds without the need for pthreads but seems to insist on dlopen dlclose even in static lib ?

Add --without-libdl.

Quoted 6 lines · Clemens Ladisch

Quoted 2 lines · Jonathan Andrews

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 ?

At Thu, 08 Mar 2012 15:14:50 +0000,

Quoted 18 lines · Jonathan Andrews

Quoted 6 lines · Clemens Ladisch

Quoted 2 lines · Jonathan Andrews

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 ?

Quoted 7 lines

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.

At Thu, 08 Mar 2012 15:14:50 +0000,

Quoted 8 lines · Jonathan Andrews

Quoted 6 lines · Clemens Ladisch

Quoted 2 lines · Jonathan Andrews

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

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

The futex address 0xae5320 occurs only once at the end of the text file so I have no idea what sets it up.

Quoted 7 lines · Jonathan Andrews

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.

Quoted 3 lines

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

Quoted 3 lines

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