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