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

[Lennart Poettering]

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
> (--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

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!

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4