Bug 1014781

Summary: pulseaudio daemon gets hung up and blocks other applications
Product: [Fedora] Fedora Reporter: Brian J. Murrell <brian.murrell>
Component: dbusAssignee: Colin Walters <walters>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 19CC: brendan.jones.it, lkundrak, lpoetter, rodd, walters
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1014588 Environment:
Last Closed: 2015-02-17 17:28:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1014588    
Bug Blocks:    
Attachments:
Description Flags
pulseaudio stack trace when hung up none

Description Brian J. Murrell 2013-10-02 19:10:45 UTC
Created attachment 806687 [details]
pulseaudio stack trace when hung up

+++ This bug was initially created as a clone of Bug #1014588 +++

Description of problem:
Applications wanting to emit a sound introduce multi-second latencies.

In addition trying to start the pavucontrol it just blocks forever with "Establishing connection..."

Version-Release number of selected component (if applicable):
pulseaudio-module-gconf-3.0-10.fc19.x86_64
pulseaudio-utils-3.0-10.fc19.x86_64
pulseaudio-module-x11-3.0-10.fc19.x86_64
pulseaudio-3.0-10.fc19.x86_64
pulseaudio-module-bluetooth-3.0-10.fc19.x86_64
alsa-plugins-pulseaudio-1.0.27-1.fc19.x86_64
pulseaudio-libs-glib2-3.0-10.fc19.x86_64
pulseaudio-libs-3.0-10.fc19.x86_64
pulseaudio-module-zeroconf-3.0-10.fc19.x86_64
pulseaudio-libs-3.0-10.fc19.i686
paprefs-0.9.10-4.fc19.x86_64
pavucontrol-2.0-1.fc19.x86_64

How reproducible:
Not on demand but eventually pulseaudio daemon will get into this state.

The only way to resolve this issue is to kill the running pulseaudio daemon (had to use -KILL as -TERM and -HUP wouldn't kill it) and another was automatically restarted fixing the problem, until it happens again, for unknown reasons.

I will attach a threaded stack trace of the pulseaudio daemon in this hung-up state.

Comment 1 Brian J. Murrell 2013-10-04 17:39:18 UTC
Any chance of getting this looked at given that it's happened to me at least half-a-dozen times today?

Comment 2 Brian J. Murrell 2013-10-11 13:42:39 UTC
You might have gathered by just looking at the stack traces, but I have confirmed that this issue seems to be related to the appearance and disappearance of my bluetooth headset.

That said, is there any reason this bug has not even been triaged?  Maybe the above detail was the missing link needed to make progress on this bug?

Comment 3 Brian J. Murrell 2013-10-17 13:25:35 UTC
Tanu Kaskinen reported on the PA discuss list about this issue:

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.

(http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-October/018955.html)

So I will re-assign to the dbus Component here to see if this can get worked out.

Comment 4 Rodd Clarkson 2013-10-21 05:24:48 UTC
I'm seeing what I suspect is this on all the computers in the lab at school.  The machines are all running Fedora 19.

I only noticed this problem about a week ago and haven't had time to comment/research until now.

I get a warning at the bottom of the gnome window saying:

----------------------
A Problem has been Reported

A problem in the pulseaudio-3.0-10.fc19 package has been detected

                                                  [ Ignore Forever ]
----------------------

This no obvious backtrace and no way to see what the problem is, where it's been reported or that something is being done about it.

Comment 5 Fedora End Of Life 2015-01-09 20:05:16 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Fedora End Of Life 2015-02-17 17:28:29 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.