On Fri, 2013-10-11 at 09:47 -0400, Brian J. Murrell wrote: > Using pulseaudio 3.0 on Fedora 19, I have been experiencing pulseaudio > hanging up to the point of needing to be killed with a SIGKILL when my > bluetooth headset disappears (i.e. out of range, or turned off, etc.). > > When this happens, the following stack trace can be observed: > > https://bugzilla.redhat.com/attachment.cgi?id=806687 > > In particular the hung thread looks like: > > #0 pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00000038f6e0dc95 in _dbus_connection_acquire_dispatch > (connection=connection at entry=0x142dab0) at dbus-connection.c:4096 > #2 0x00000038f6e0f6fc in dbus_connection_dispatch > (connection=connection at entry=0x142dab0) at dbus-connection.c:4531 > #3 0x00000038f6e0fcca in _dbus_connection_read_write_dispatch > (connection=0x142dab0, > timeout_milliseconds=timeout_milliseconds at entry=-1, > dispatch=dispatch at entry=1) at dbus-connection.c:3646 > #4 0x00000038f6e0fd60 in dbus_connection_read_write_dispatch > (connection=<optimized out>, > timeout_milliseconds=timeout_milliseconds at entry=-1) at > dbus-connection.c:3729 > #5 0x0000003914e4821e in pa_dbus_wrap_connection_free (c=0x1402fd0) at > pulsecore/dbus-util.c:329 So dbus_connection_read_write_dispatch() is blocking. We give -1 as the timeout parameter, which means infinite timeout, but pa_dbus_wrap_connection_free() calls dbus_connection_close() just before calling dbus_connection_read_write_dispatch(), and I would expect that there would never be a reason to block if the connection has been closed. So, this looks like a D-Bus bug, but I'm not sure about that. -- Tanu
