[pulseaudio-discuss] Semaphore lockup when using threaded mainloops excessively

Daniel Mack zonque at gmail.com
Fri Apr 1 06:24:07 PDT 2011

Hi Colin,

On Fri, Apr 1, 2011 at 2:28 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Oh jeez... I just realised I misread on of your mails (it was a long
> day, I was tired <better excuse goes here>).

No worries :)

> I thought you were saying your daemon crashed on *startup* on linux...
> before your test was run :s

No, the startup is fine. The bug is about some sort of race condition
when starting up and tearing down runloops, contexts and streams in a
wild manner and very excessively from a client. I happend to trigger
these category of bugs during my development of the PulseAudio driver
for OS X, and I wrote the test to minimize the amount of code it needs
to reproduce it.

Even though the test results in slightly different effects (on the
daemon's side) for OS X and Linux, I think it could be the same kind
of bug after all. From the backtrace on Linux, it looks like a message
is not fully queued or dequeued, and hence the payload is corrupted. A
similar thing could have caused a semaphore not to be posted which
makes the daemon hang on OS X.

I'll debug this further, but I still know too less about the internal
async messages that are being passed around, the queues and all the
locking theory. Maybe Lennart can shed some light?

> Will take a look at your test to see if I can reproduce here, but as I
> said before, it may not be until Sunday... hopefully some of the others
> can chime in.

No hurries, and thanks for caring :)


More information about the pulseaudio-discuss mailing list