poll(), gdb, threads, alsa-lib, deadlock

[Michael Schwendt]

On Wed, 8 Jul 2009 12:28:55 +0200, Dominik wrote:

> On Wednesday, 08 July 2009 at 11:00, Michael Schwendt wrote:
> > I'd like another pair of eyes as what I see in a backtrace looks strange.
> > The full backtrace is attached, two excerpts inline below.
> > 
> > With Fedora 11 (and never before) I see deadlocks in Audacious
> > occasionally. It's not too easy to reproduce, but starting something
> > resource-hungry while playing ogg/mp3 makes the player hang up
> > occasionally.
> 
> Actually, I see that on Fedora 10, too.

Do you remember when you ran into it for the first time?
alsa-lib was upgraded for F10 at beginning of May, for example. [Perhaps
I need to diff in that area.]

On F11 I can downgrade audacious* to the packages before the first set of
alsa patches, and the problem is reproducible. The upstream updates 2.0
and 2.1beta1 are not safe, since they contain new problems (and not the
latest alsa plugin and even one or a few race conditions).

> Pressing pause and then play makes it
> return to normal again, for some time. Not sure if it's the same issue,
> because only the playback thread seems to hang (as if "pause" was pressed).

Very likely it's related -- and yes, in one or two cases I could click
stop, too, to end the deadlock. Multiple threads are used and communicate
with eachother via glib2 conditions (GCond) and proper mutex locking.
Wherever infinite timeouts are used when waiting for conditions and a key
thread doesn't return from a syscall, other threads might wait endlessly,
too.