[pulseaudio-discuss] deadlocks when running pulseaudio with --high-priority=1

[Colin Guthrie]

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
> (--high-priority=1). 
> 
> 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
> 
> At some point, pulseaudio gets stuck and backtrace shows its
> stuck in memblock.c:pa_memblock_unref() -> memblock_free() 
> -> pa_mutex_lock().
> 
> There's a FIXME comment already in the function, so I guess this
> is known. 
> 
> 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. ;)
> 
> 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...
> 
> br,

I'd make a ticket in trac and attach what you have just so it doesn't
get lost.

Unf. I don't know much about the core of pa so can't really help
technically.

Col