[pulseaudio-discuss] pulseaudio hangs up when bluetooth headset disappears

[Tanu Kaskinen]

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