#381: bug in the EsounD emulation of PulseAudio causing gnome-panel to freeze
------------------------------+---------------------------------------------
Reporter: timrichardson | Owner: lennart
Type: defect | Status: new
Priority: normal | Milestone:
Component: module-esound-* | Severity: major
Resolution: | Keywords:
------------------------------+---------------------------------------------
Comment (by coling):
Replying to [comment:7 timrichardson]:
> Here is why I think it is a pulseaudio bug:
>
> 1) "Esound" is actually part of pulseaudio now, as I understand it. I
use the Debian package "pulseaudio-esound-compat" which is described as a
"drop in replacements for the ESD sound server". It does this so the gnome
applications think they are still using ESD, but it is pulseaudio code
doing the work. So the call in the trace to esd_sample_play is in
pulseaudio code, I think, despite appearances.
Not quite. The call to esd_sample_play in shown as being from
/usr/lib/libesd.so.0 which is nothing to do with pulse itself. It is still
provided by esound daemon source tarball.
Pulse implements an esound compatible server, but it has nothing to do
with esound ''clients''
That's not to say the bug itself is not in pulseaudio, but just that buggy
client code is not pulse's fault.
> 2) after the freeze happens, I can stop the gdm session (eg sudo
/etc/init.d/gdm stop
> Normally this would clean up user processes. But after the freeze, the
remainging user processes include pulseaudio.
> The only way to be able to restart gdm is to kill pulseaudio, and it
needs a hard kill (-9)
> So when this bug happens, the pulseaudio daemon gets stuck. So that's
another reason why I think it is a pulseaudio bug
This could be indicative, and that's why I made my comments above about
esd auto spawning. LIke I say the libesd will autospawn /usr/bin/esd
(whcih should be a symlink to/rename of the esdcompat script installed by
pulseaudio. If esd-based autospawning is enabled it could expose some
nasty thread based problems which could in turn lead to the weird stack
trace you see. I'm not sure it's overly likely as I would expect to see
more pulse related function calls if this were the case but as I've had
issues with this in the past I mentioned it above.
> 3) The Ubuntu thread I link to says that the connection between this
pulseaudio freeze and the freeze of gnome-panel is: gconf daemon is locked
by pulseaudio, and pulseaudio then freezes, stopping many other things in
the gnome-desktop.
It is perhaps the loading of module-gconf in pulse that is causing this
lock. Perhaps when the sample is played, gconf is locked, esd based
autospawning menetioned above triggers autospawn of pulseaudio whcih tries
to load module-gconf which in turn cannot get a lock as it's already
locked in the process that loaded it and thus causes a deadlock. It would
be pretty bizarre, but this is possibility. Again, please report if you
have and /etc/esd.conf file and if creating one as I mentioned above helps
if you do not.
> That is something about which I have no clue, but if it's true, it seems
to be pretty poor behaviour of pulseaudio daemon. Below are the processes
that are left alive after the gdm stop (normally they would all have
exited), and you can see the gconfd is among them.
If pulse indeed is waiting for a lock and deadlocks things then yeah I
agree, but please check the the things I've already suggested before
looking to guess where the problem is :) I don't know how gconf locking
works but if it is indeed where the problem is, then either:
1. disabling esd auto-spawn, or
2. removing module-gconf from pulse's scripts
should alleviate the problem (albeit the latter with functional
degradation as a result, but it would help debug where the issue lies).
--
Ticket URL: <http://pulseaudio.org/ticket/381#comment:8>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
