Olivier Blin <[email protected]> writes: > Olav Vitters <[email protected]> writes: > >> On Fri, Jul 27, 2012 at 11:35:44PM +0200, Olivier Blin wrote: >>> gdb --pid can be used to get a stack trace then >> >> gnome-shell: >> >> The hang is in thread 1. Hangs in glibc, with Pulseaudio calling it. >> Seems exactly like the mplayer issue. I've seen this hang before >> Pulseaudio 2.1. >> >> Thread 1 (Thread 0x7f975cfe8900 (LWP 2367)): >> #0 pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:144 >> #1 0x00007f97558a4aa0 in pa_threaded_mainloop_wait (m=0x21bdf00) at >> pulse/thread-mainloop.c:206 >> #2 0x00007f97460aaa0b in pulse_driver_play (c=0x21b5280, id=<optimized >> out>, proplist=0x704c9c0, cb=<optimized out>, userdata=<optimized >> out>) at pulse.c:1085 >> #3 0x00007f975955624e in ca_context_play_full (c=c@entry=0x21b5280, >> id=id@entry=1, p=0x704c9c0, cb=cb@entry=0x0, >> userdata=userdata@entry=0x0) at common.c:522 >> #4 0x00007f97595565cf in ca_context_play (c=0x21b5280, id=1) at common.c:462 > > (huge backtrace snipped) > > This looks exactly like this Debian bug, which was caused by a > pthread_cond_wait patch in glibc: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651746
Redhat has a similar report: http://sourceware.org/ml/libc-alpha/2012-01/msg00002.html Both distros revert a pthread_cond_wait change. I'll do the same in our glibc package. -- Olivier Blin - blino
