[pulseaudio-discuss] deadlocks when running pulseaudio with --high-priority=1
lennart at poettering.net
Mon Dec 17 14:00:49 PST 2007
On Thu, 13.12.07 21:05, Kai.Vehmanen at nokia.com (Kai.Vehmanen at nokia.com) wrote:
> Hello all,
> this is probably a known issue, but I'm constantly hitting
> a deadlock when running Pulseaudio (0.9.7) with SCHED_FIFO
> I can reproduce it as follows:
> - run pulseaudio (self-compiled, debian stable) with --high-priority=1
> - first client: while [ 1 ] ; do aplay -D pulse foo.wav ; done
> - second: while [ 1 ] ; do aplay -D pulse foo.wav ; done
Uh, doesn't happen here.
> At some point, pulseaudio gets stuck and backtrace shows its
> stuck in memblock.c:pa_memblock_unref() -> memblock_free()
> -> pa_mutex_lock().
Could you please paste the whole backtrace somwhere?
> There's a FIXME comment already in the function, so I guess this
> is known.
YOu mean the FIXME in memblock_free()? That's just a comment about a
potential optimization here. It's not a bug. It's just that we are not
fully lock-free in this function and it would be better if we
where. But this doesn't make the function incorrect or buggy or anything.
> I made a fix in my local tree which uses pa_mutex_trylock() (a new
> funtion implemented using pthread_mutex_trylock()) and nanosleep()
> to avoid the priority inversion (spins until it gets the lock).
> With this patch, Pulseaudio now survices the above stresstest.
> Of course, nanosleeping() in RT context is very, very ugly,
> but better than a deadlock, at least. ;)
Uh? That mutex does priority inheritance anyway. If you get a lockup
than there's something wrong with the locking order, it's most likely
not a prio inversion problem.
> Any ideas how to go forward? I could clean up the code and send
> a patch, or alternatively try out a different approach. I don't
> fully grok all the code in memblock_free() yet, so it's hard to
> say how big of a task it would be to make this totally lock-free.
> At least doesn't look to be very straighforward...
A full backtrace over all threads would be of great help!
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss