GNOME Bugzilla – Bug 431711
Enabling ESD sounds hangs gnome-panel
Last modified: 2012-02-28 20:32:54 UTC
Please describe the problem: Enabling Desktop sounds (ESD) causes gnome-panel to stop functioning as soon as the desktop welcome sound plays. Killing ESD process allows panel to continue functioning. The following pop-ups appear after killing esd process: The panel encountered a problem while loading "OAFIID:GNOME_FastUserSwitchApplet". The panel encountered a problem while loading "OAFIID:GNOME_SystemTrayApplet". The panel encountered a problem while loading "OAFIID:GNOME_ClockApplet". The panel encountered a problem while loading "OAFIID:GNOME_MixerApplet". ... Do you want to delete the applet from your configuration? Steps to reproduce: 1. Enable desktop sounds with System->Preferences->Hardware->Sound 2. Check Enable software sounds (ESD) and System sounds 3. Log out, and log back in. Actual results: Gnome-panel displays, but none of the icons or functionality works until esd process is killed from another vty. Expected results: Gnome-panel should not block on sound problems (or should time out with an error in a few seconds) Does this happen every time? Yes Other information: This is identical to the bug I reported last year against gnome-terminal that appeared in FC5, but disappeared when I moved to FC6. Now I'm using F7T3, and the problem is back. (http://bugzilla.gnome.org/show_bug.cgi?id=329647#c6). Not having desktop sound was so disruptive, and the move to FC6 fixing the problem left the bug unresolved. I have a bug logged against pidgin concerning it crashing as soon as it attempts to play a sound. Initial comments on the bug seem to place the problem on gstreamer not having re-entrant code in _gst_parse_yylex. Don't know if the two are related problems, but they are both caused by sound functions. gnome-*-2.18.0-1.fc7.x86_64 gstreamer-tools-0.10.12-1.fc7 gstreamer-plugins-farsight-0.12.0-1.fc7 gstreamer-0.10.12-1.fc7 gstreamer-0.10.12-1.fc7 gstreamer-plugins-base-0.10.12-2.fc7 gstreamer-plugins-good-0.10.5-5.fc7 gstreamer-plugins-pulse-0.9.4-4.fc7 gstreamer-plugins-base-0.10.12-2.fc7
See this bug thread and comments: http://bugs.archlinux.org/task/6544
I've had desktop sounds enabled from some time now, but I see this problem (and associated problems) from time to time. Gnome apps (for the most part) hang on starting and when you 'killall' esd then they work again. It seems to be something that happens during start up of applications, because stuff that was running will still work fine (for example a gnome-terminal window, or gedit), but if you try to run something new they sometimes hang. I'm happy to help with debugging this. Tell me what you need.
I have the same problem with Fedora Test3. Gnome panel hangs shortly after login when esd is enabled. Editing setting enable_esd value to "false" in $HOME/.gconf/desktop/gnome/sound/%gconf.xml allows gnome panel to load without problem
Having a similar problems with Fedora 7 Test 3 and Fedora 7 Test 4 except that often the panel will not even show up.
1. Tried again, but reverted gstreamer and its dependencies to FC6 versions. Did not revert esound. Problem persisted. 2. Kept gstreamer at FC6 version and reverted esound to FC6 version and tried again. Problem vanished. 3. Important(?) note: When reverted to the FC6 version, esd is called as follows (output from ps aux | grep esd): /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 17 whereas when using the F7T4 version, esd is called as follows: /usr/bin/esd -nobeeps 4. Upgraded gstreamer to Fedora Rawhide versions, but kept esound at FC6 version. System appears to be working properly.
Problem reappeared after the latest updates.
The panel doesn't do anything with sound, so it's likely a problem in our stack (libgnome, I'd guess). Could people getting this issue attach the blocking panel with gdb and get a stack trace? We'll know where this is blocking and we'll be able to reassign the bug.
Not sure if this is relevant, but this is from fedora-test-list and seems to be related. Pasted from this thread: https://www.redhat.com/archives/fedora-test-list/2007-April/msg00377.html ------------------------------------------------------------------------ [22.Nis.07 11:56 +1000] Rodd Clarkson: >On Fri, 2007-04-20 at 02:01 +0300, Sertaç Ö. Yıldız wrote: >>[19.Nis.07 12:58 -0400] Andy Baumhauer: […] >>> I was unable to confirm which applet was hanging the panel. I ended >>> up fixing the problem my removing .gnome, .gnome2, and .gconf >>> (probably overkill). >> >> I suspect this is about system sounds. Killing esd ‘unhangs’ gnome here. >> Maybe by removing .gconf you just unset /desktop/gnome/sound/enable_esd? > >I've seen the exact same thing too. A quick 'killall esd' fixes things, >but I guess it shouldn't be happening in the first place. > >Anyone make a suggestion on where to start debugging this. Would a >hardware profile be a good start, or do we need a backtrace of esd (and >how do we get this), or is esd just an innocent bystander. It looks like a problem in ALSA. This is the backtrace before I kill esd: #0 0x00c1d410 in __kernel_vsyscall () #1 0x00b2b4fb in poll () from /lib/libc.so.6 #2 0x047a6754 in snd_pcm_wait_nocheck (pcm=0x9eb4ec0, timeout=-1) at pcm.c:2302 #3 0x047a693f in snd_pcm_wait (pcm=0x1, timeout=-1) at pcm.c:2271 #4 0x047c11d2 in snd_pcm_rate_drain (pcm=0x9eb44f0) at pcm_rate.c:1091 #5 0x047a1062 in snd_pcm_drain (pcm=0x9eb42b0) at pcm.c:1092 #6 0x048c57d5 in esd_audio_flush () at audio_alsa09.c:489 #7 0x0804ba6f in wait_for_clients_and_data (listen=4) at clients.c:337 #8 0x0804a972 in main (argc=Cannot access memory at address 0x1) at esd.c:1017 #9 0x00a7af10 in __libc_start_main () from /lib/libc.so.6 #10 0x080494b1 in _start () #0 0x00c1d410 in __kernel_vsyscall () and my audio device: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: Toshiba America Info Systems Unknown device ff00 Flags: bus master, fast devsel, latency 0, IRQ 22 Memory at d0340000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 >I'm willing to try and debug, but not sure were to start. I'll file a bug over the weekend if there isn't one. ------------------------------------------------------------------------
This might be related, although to be sure, we'd need a stack trace of the panel.
This might be a problem in alsa, control-center, libgnome or even gstreamer but I don't think gnome-panel is the appropriate component. fwiw, I filed a bug against esound here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238680
I disagree that this isn't a gnome-panel bug. You are correct that another piece of code may be the source of the hang, but the behavior of gnome-panel is *not* appropriate. Needing sound is not a critical function of gnome-panel. If gnome-panel is blocking on startup because of a problem in a sub-process, it should wait an appropriate time, then timeout and continue. Pop-up an error message if you want, just don't block indefinitely! Without gnome-panel, Gnome, and your desktop is worthless. I call that a bug. Punting this into another corner won't fix the bug in gnome-panel. Esound is probably the source (ESD), and it is a gnome project, so fixing the interaction shouldn't be that hard.
gnome-panel is not blocking because of a problem in a subprocess. It's a library that it is using that is blocking the panel process because esd is blocked. gnome-panel uses libgnome which uses the esd library. The esd library is probably blocked while contacting the esd daemon, which maybe doesn't reply because it's blocked within alsa. This is most probably not a panel problem. But we still need a stack trace to be sure...
Andrew, this isn't a panel bug because I've seen the same behavior with gnome-panel successfully loaded or even when running gnome applications inside xfce etc. without gnome-panel. Anyway if it will help here's a backtrace from gnome-panel when it hanged:
+ Trace 131908
Thanks. Reassigning to esound: having the esd client blocking because of the esd server not replying is not good (although, in the end, it's probably because alsa is doing some bad things). All GNOME applications can be affected.
I've attached several stack traces that occur during the hang. The first is gnome-panel, then gnome-session, then esd (esound), followed by a process status for the user... Trace of gnome-panel during hang:
+ Trace 131923
Thread 1 (Thread 46912505298800 (LWP 3903))
andy 3821 3756 0 10:59 ? 00:00:00 gnome-session andy 3884 3821 0 10:59 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session andy 3887 1 0 10:59 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session gnome-session andy 3888 1 0 10:59 ? 00:00:00 /bin/dbus-daemon --fork --print-pid 4 --print-address 8 --session andy 3891 1 0 10:59 ? 00:00:00 /usr/libexec/gconfd-2 6 andy 3894 1 0 10:59 ? 00:00:00 /usr/bin/gnome-keyring-daemon andy 3896 1 0 10:59 ? 00:00:00 /usr/libexec/gnome-settings-daemon andy 3900 3821 0 10:59 ? 00:00:00 /usr/bin/esd -nobeeps andy 3902 3821 0 10:59 ? 00:00:00 compiz --sm-client-id default1 gconf andy 3903 3821 0 10:59 ? 00:00:00 gnome-panel --sm-client-id default2 andy 3906 3821 0 10:59 ? 00:00:00 nautilus --no-default-window --sm-client-id default3 andy 3909 1 0 10:59 ? 00:00:00 gnome-volume-manager --sm-client-id default4 andy 3912 3902 0 10:59 ? 00:00:00 gtk-window-decorator andy 3916 1 0 10:59 ? 00:00:00 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=16 andy 3921 3821 0 10:59 ? 00:00:00 bluetooth-applet andy 3927 3821 0 10:59 ? 00:00:00 nm-applet --sm-disable andy 3930 3821 0 10:59 ? 00:00:00 /usr/bin/python -tt /usr/bin/puplet andy 3931 3821 0 10:59 ? 00:00:00 python /usr/share/system-config-printer/applet.py andy 3935 1 0 10:59 ? 00:00:00 gnome-power-manager andy 3936 3821 0 10:59 ? 00:00:00 pam-panel-icon --sm-client-id default0 andy 3938 1 0 10:59 ? 00:00:00 /usr/libexec/gnome-vfs-daemon andy 3949 1 0 10:59 ? 00:00:00 /usr/libexec/wnck-applet --oaf-activate-iid=OAFIID:GNOME_Wncklet_Factory --oaf-ior-fd=17 andy 3951 1 0 10:59 ? 00:00:00 /usr/libexec/trashapplet --oaf-activate-iid=OAFIID:GNOME_Panel_TrashApplet_Factory --oaf-ior-fd=23 andy 3952 1 0 10:59 ? 00:00:00 ./escd --key_Inserted="/usr/bin/esc" --on_Signal="/usr/bin/esc" andy 3953 3952 0 10:59 ? 00:00:00 [netstat] <defunct> andy 3965 1 1 10:59 ? 00:00:00 /usr/bin/python -E /usr/bin/sealert -s andy 3973 1 0 10:59 ? 00:00:00 /usr/libexec/gam_server andy 3976 1 0 10:59 ? 00:00:00 /usr/libexec/mapping-daemon andy 3990 1 0 10:59 ? 00:00:00 /usr/libexec/notification-area-applet --oaf-activate-iid=OAFIID:GNOME_NotificationAreaApplet_Factory --oaf-ior-fd=18 andy 3992 1 0 10:59 ? 00:00:00 /usr/libexec/fast-user-switch-applet --oaf-activate-iid=OAFIID:GNOME_FastUserSwitchApplet_Factory --oaf-ior-fd=29 andy 3994 1 0 10:59 ? 00:00:00 /usr/libexec/clock-applet --oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory --oaf-ior-fd=35 andy 3996 1 0 10:59 ? 00:00:00 /usr/libexec/mixer_applet2 --oaf-activate-iid=OAFIID:GNOME_MixerApplet_Factory --oaf-ior-fd=41 andy 3998 1 0 10:59 ? 00:00:00 /usr/libexec/multiload-applet-2 --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=47 andy 4000 1 0 10:59 ? 00:00:00 /usr/libexec/sensors-applet --oaf-activate-iid=OAFIID:SensorsApplet_Factory --oaf-ior-fd=53 andy 4005 1 0 10:59 ? 00:00:00 /usr/libexec/notification-daemon andy 4045 1 0 10:59 ? 00:00:00 gnome-screensaver
It's a known problem that libesd blocks when communicating with esd. Of course, this causes no end of problems if communication with esd breaks down for any number of reasons. This is one of those bugs that on the surface looks like it would be easy to fix. However, fixing this would be a classic case of yak shaving. Changing the read/write code would involve touching a lot of places in esound that are a delicate balance of interlocking bugs. I keep hoping that soon PulseAudio will come and save the day.
There's the same bug in ALSA's upstream bug tracker: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1306
It seems to be related with the hda_intel and Alsa. Building esd with --disable-alsa fixes the problem (but makes flash videos mute). It seems to be introduced with 0.2.37.
In the case of ArchLinux (http://bugs.archlinux.org/task/6544) it seems to be the "auto-spawn" option that brings to problems. The problem was introduced with esd-0.2.37, that switched by default the auto-spawn configure option to 0. Moving it back to 1, everything now seems to work.
Martin Stransky mentions that the problem is most likely due to a bug in alsa-lib, which can be worked around using snd_pcm_drop instead of snd_pcm_drain: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238680#c21 Patch at: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156695
Created attachment 90018 [details] [review] esound-0.2.38-drain.patch
I've just submitted patches to both esound and libgnome's gnome-sound.c to fix hanging issues if/when the esd daemon hangs. see bug #542391 and bug #542296 It was not hard to fix the read/write/connect code to not block on broken sockets.
I just tried revision 500 from the svn and the problem is still occurring. I am using Ubuntu 8.04, and yes, I removed PulseAudio. After uninstalling all packages pertaining to PA and ESD and disabling "Enable software sound mixing (ESD)" and "Play system sounds" in "System->Preferences->Sound", I restarted my computer and there was no problem. Then I installed the package esound from Synaptic. I restarted and there was still no problem. When I enabled "Enable software sound mixing (ESD)" and "Play system sounds" in "System->Preferences->Sound" and restarted, that's when GNOME applications screwed up. After logging in, I get the welcome sound. Then I get my Desktop and AWN working but GNOME panel, my desktop items and every GNOME application stops working. Mozilla Thunderbird works. Maybe some others I haven't tried but the only apps I can try are the ones in my AWN launcher. I restart X and log into a FailSafe terminal and sudo apt-get remove esound. I also purge it as well. Then I restart and disable systems sounds. From SVN, I download esound revision 500 from trunk, and install it. Without enabling system sounds, I restart and everything works great. Then I enable system sounds and restart and again after logging in I get the welcome sound and no other GNOME apps working. Let me know if you need more info.
I forgot that you also altered gnome-sound.c!!! So, I tried it again with a rebuild of the new gnome-sound.c in my current version of libgnome2-0 (the installed version is 2.22.0-0ubuntu1). Again, with the system sounds disabled, it restarted just fine. But when I enabled the system sounds, the problem still occurred. But it was a little better. For example, the logout sound worked when I restarted and there was no hangup with the restart. Usually, at this point, there is. When I logged in, I got the welcome sound just fine. But this time, I could see the gnome-panel! I was able to click on it, JUST ONCE! I wasn't able to do that before. But none of my desktop items showed up. And again, no GNOME apps were working. I uninstalled esound again from a failsafe terminal and it's back to normal without system sounds. Should I have built the newest version of libgnome from trunk? Instead of patching it with my version? Let me know if you need more info.
If I change the auto-spawn option in /etc/esound/esd.conf to 1 (default was 0), system sounds work perfectly! Thank you Giacomo Rizzo for the suggestion!
"esound" has not seen code changes for more than three years according to http://git.gnome.org/browse/esound/log/ , and it will not see further active development anymore according to its developers. Closing this report as WONTFIX - Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.