I don't know if I'm alone having this bug but it seems I found a race condition leading to a hang of gnome-session when system is heavily loaded and generally after a fresh reboot of my laptop. I don't sure if problem is in media-sound/esound-0.2.36 and/or gnome-base/gnome-session-2.14.2 but to fix this issue I must either ... 1) kill the running 'esd' process when gnome-session hangs after a login (the session continues normally after that) or to fix the problem permanently 2) apply the following patch to 'gsm-sound.c' requesting to gnome-session to start esound server as a background process +++ gnome-session/gsm-sound.c 2006-08-03 10:45:02.000000000 +0930 @@ -57,7 +57,7 @@ GError *err = NULL; time_t starttime; - if (!g_spawn_command_line_async (ESD_SERVER" -nobeeps", &err)) + if (!g_spawn_command_line_async (ESD_SERVER" -nobeeps &", &err)) { g_warning ("Could not start esd: %s\n", err->message); g_error_free (err); The patch works fine w/o any side effect.
g_spawn_*_async should not block, the '&' is strictly speaking redundant. Does the message "Could not start esd:" show up in your ~/.xsession-errors file before or after killing esd (without the patch of course) ?
Bug confirmed here on x86 since one month. I just killed esd after fresh reboot, and the gnome desktop appear. When the desktop hangs : # ps aux | grep esd fab 8018 0.0 1.2 3784 2336 ? SL 21:41 0:00 /usr/bin/esd -nobeeps fab 8025 0.0 0.2 2924 508 ? Ss 21:41 0:00 /usr/bin/esd -nobeeps
Created attachment 93373 [details] content of .xessions-errors content of .xsession-errors when the desktop hangs
Created attachment 93374 [details] emerge --info emerge --info
Created attachment 93376 [details] emerge --info Exactly the same as above for the my .x-session file. Here is my emerge --info.
Can you run gnome-session in gdb and create a backtrace when it hangs (with debugging info) ?
Created attachment 93385 [details] gnome-session backtrace Not very familiar with gdb but this should be OK. Repeated twice to be sure. When I start 'bt' I receive a warning from gdb (Previous frame inner to this frame (corrupt stack?)) but it's possibly because I compile with the -fomit-frame-pointer flag.
Created attachment 93395 [details] esd backtrace Backtrace for the 'locking' esd process. Hope this help to find the bug.
I found something *very* weird and now we can change the Summary of the bug from "gnome-session-2.14.2 hangs (often) after a fresh boot" to "gnome-session-2.14.2 hangs (less often) after a fresh boot" For same laptop (of coarse) -Occurence of the bug with vanilla-sources-2.6.17.7 : 50% to 60% -Occurence of the bug with vanilla-sources-2.6.18-rc3 : ~10% Hopefully when gnome-session hangs backtraces provided are the same for both kernels (fiou!) but with kernel 2.6.18-rc3 I saw only once instance of esd daemon instead of two which seems typical of 2.6.17 kernels. Patrice - don't upgrade your kernel if you have the problem !!! Time to invite another party to join us ?
Created attachment 93419 [details] two parallel esd process : backtrace from gdb Too late. Unfortunately, I upgraded my kernel last week to 2.6.17-r4 (gentoo-sources), and, I made a clean up of old kernels with their config files. I tried to boot on a 2.6.16-r12, same issue. Bug's occurence with both kernels : 100%. On my second computer which is full ~x86, this bug appeared two months ago, but disappeared itself a few weeks later. But, bad luck : it happened once this morning on it :) When it happens, the xrdb process is marqued as defunct with the ps aux command. I also noticed that a restart of the xdm init script fix the issue until next reboot (my hack since one month). The attached file contains the two esd process's backtrace from gdb. I'll attach another file containing the gnome-session backtrace. I don't know if debug infos are suffisant, maybe I should rebuild my world with the debug useflag, but in this case, it will take time.
Created attachment 93420 [details] gnome-session backtrace from gdb
please comment on the duped bug. *** This bug has been marked as a duplicate of 133599 ***
(In reply to comment #12) > please comment on the duped bug. > > *** This bug has been marked as a duplicate of 133599 *** > bug #133599 is not duplicate of this bug (I had it also, but now it's fixed) On my systems, g-v-m is not launched on startup : I don't want it. (and I think bug #133599 has been fixed : it is duplicate of bug #140040)
I forgot most important : please reopen this bug. Definitively not duplicate : splashscreen disappear, the two panel appear in top and bottom of the screen, but they are empty, and nothing else. Then, I login to a tty, and : $ killall esd Switch back to X, and the gnome desktop is here. Thanks.
I think I found a workaround, from the gnome menu : Desktop --> Preferences --> Sound In the Sounds tab : [x] Enable software sound mixing (ESD) [ ] Play system sounds And gnome start without this bug. If I check 'Play system sounds' ==> bug after a reboot.
I forgot to tell that I recently did a fresh installation of gentoo on a toshiba laptop, with gnome-light, and unfortunately, this bug is also here.
(In reply to comment #15) > I think I found a workaround, from the gnome menu : > > In the Sounds tab : > > [x] Enable software sound mixing (ESD) > [ ] Play system sounds Not working for me. I don't remember the last time I unchecked this feature so it's not a fix for this bug. Patrice seems right about bug 133599 not being a duplicate of this bug. Problems described in bug 133599 are classified FIXED for me (& I insist *for me*) :-)
> Not working for me. I don't remember the last time I unchecked this feature so > it's not a fix for this bug. > If I check 'Play system sounds' ==> bug after a reboot. It's quite logical because gnome-session is waiting something from esd & there is no need to launch esd when you are not playing system sound. I noticed that too. Killing esd to restore desktop just confirms bug is somewhere in gnome-session/esd (compatibility issue ?) or deeper in the system (beyond esd ?).
(In reply to comment #12) > > *** This bug has been marked as a duplicate of 133599 *** > John, finally if you're right just do the following thing to fix bug 133599. It should work too if it's the same bug as this one (15 successful fresh reboot in a row - initially it was 50% chances to hang the first time I filled the bug)! 1) Upgrade your kernel to 2.16.8-rc3 (not sure it's really important), 2) Dump/build-in alsa sound drivers in your kernel (not as modules) !!! My fix probably hide the real problem which is likely in media-sound/esound and/or media-libs/alsa-lib packages (probably something like gnome-session starting esd daemon when alsa has not finished to load). This bug just show a weakness (& not a bug) in gnome-session which seems not being able to cope with an unexpected behavior/bug/whatever of esd daemon. Like Patrice, I thing this bug should be reopened and reassigned to someone else than /dev/null party.
Look at this guys. Same problem with FC5 ... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189744
Mayber related : http://bugzilla.gnome.org/show_bug.cgi?id=345187 And look at this one : http://bugzilla.gnome.org/show_bug.cgi?id=311240 [quote] You could just run esound as a daemon instead of having applications spawn one. The latter use pattern is strongly discouraged. |...] I'm no longer willing to support autospawning, since it's fundamentally broken. [/quote] ==> on my buggy gentoo, I re-activate system sounds, and I ran : # rc-update add esound default ==> works well now.
It's apparent to me this is not a duplicate
It seems upstream isn't willing to support esd in non-daemon mode. I'm willing to go with that. Gstreamer is the future of sound in gnome anyway, so esd will eventually die. Thanks for finding this, we'll start recommending anyone using esd run it at system startup.
(In reply to comment #23) > > Thanks for finding this, we'll start recommending anyone using esd run it at > system startup. > Please, can you add this info in the ebuild to inform all users ?
