[Xcb] pulseaudio hangs in sem_wait() from libpthread-stub.so

[Uli Schlachter]

Hi,

On 22.11.2012 23:14, Stefan Stefanov wrote:
> Since 2009 there is support for sem_* functions in libpthread-stubs.so
> http://lists.freedesktop.org/archives/xcb/2009-August/004983.html
> 
> In my distro libpthread-stubs-0.2 is installed.

Uhm. That patch is only in Debian, not upstream. And it was reverted later due
to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548240
(Which IMHO is a good thing[0]).

So why is Crux Linux applying a patch to its pthread-stubs that no one else uses?

> You can read the whole topic-thread from pulseaudio mailing list, but
> is most important:
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-November/015392.html

Ok, then the bug is... somewhere else. According to your backtrace, you have two
threads running. This should mean that libpthread is loaded. However,
pthread-stubs marks all the symbols that it exports as weak aliases. This means
that once the real libpthread is used, the functions in pthread-stubs should not
be called.

So someone now should figure out why pthread-stubs is still being used...

Is pulseaudio (transitively) linked against libpthread? If not, at which point
does libpthread get loaded, by which library and why exactly?

For the first question, you could check "ldd /usr/bin/pulseaudio | grep
pthread". For the second question I have no idea.

However, I would just suggest Crux Linux to get rid of sem_wait in
libpthread-stubs and the whole problem disappears.

Cheers,
Uli


[0]:  Debian applying a patch to pthread-stubs which makes it call pause(). IMHO
that is against the "spirit" of pthread-stubs which is to assume just a single
thread and thus that everything works. Simulating a deadlock doesn't fit here.
-- 
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
                     -- Douglas Adams