Description of problem: Sometimes, and unpredictably, on logout or shutdown/reboot gnome-session crashes. The only real evidence that this happened is that instead of a logout bug-buddy starts a feverish activity but before one is able to do anything with what is recorded there gnome-session really terminates and all evidence is gone. At least I was never fast enough to be able to copy na info there before all parent processes vanished. I was unable also to find any traces in log files. With one exception. Below is what looks like a relevant fragment of .xsession-errors file after such event. This is for a 'root' login on a machine which was freshly rebooted to check the latest updates so all libraries were current. Here it goes: Saving session: gnome-terminal --window-with-profile-internal-id=Default --show-menubar --role=gnome-terminal-3047-444216540-1183248040 --active --geometry 80x37+208+34 --title root@dyna0:/mnt/spare/updates/packages --working-directory /mnt/spare/updates/packages --zoom 1 Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0. This shouldn't happen! --- Hash table keys for warning below: --> file:///root (nautilus:2979): Eel-WARNING **: "nautilus-directory.c: directories" hash table still has 1 element at quit time (keys above) Of course all over the place are repeated warnings that "... this program is likely to crash, leak or unexpectedly abort soon..." (see bug 241959) so maybe those are more than just a noise? Version-Release number of selected component (if applicable): gnome-session-2.19.4-2.fc8 metacity-2.19.21-1.fc8 nautilus-2.19.4-1.fc8 How reproducible: you never know
I got a similar crash again. "This shouldn't happen!" sequence in .xsession-errors could be a red herring as I have seen a similar scary stuff too for sessions which terminated apparently in a normal way. There are indications, although I do not have a smoking gun, that this is wnck-applet crashing. gnome-panel-2.19.4-1.fc8
The next crash of the same sort happened again. This time right after gnome-panel was updated to 2.19.4-2.fc8 so, I guess, this applies to 2.19.4-1.fc8 (but log says that only some ownership issues were fixed). After a crash /usr/libexec/wnck-applet does not go away after 'kill'. 'kill -9 ...' removes that process though. With a help of SysRq this process shows only on a list of tasks like that: wnck-applet T ffff81000994d300 0 3031 1 (NOTLB) ffff8100082f9da8 0000000000000046 ffff8100082f9e78 0000000000000246 ffff81001d246020 ffff81000b4be000 ffff81000b11efb0 ffff81000b4be268 00000000082f9ef8 ffffffff8125a7b6 ffff81001d246020 ffffffff8107217f Call Trace: [<ffffffff8125a7b6>] _spin_unlock+0x17/0x20 [<ffffffff8107217f>] utrace_report_jctl+0x1b0/0x1c6 [<ffffffff8103e264>] finish_stop+0x57/0x8a [<ffffffff8103f485>] get_signal_to_deliver+0x315/0x3e7 [<ffffffff81009093>] do_notify_resume+0x9c/0x727 [<ffffffff8125aa7c>] _spin_unlock_irq+0x24/0x27 [<ffffffff81009ddc>] int_signal+0x12/0x17 gnome_segv2 ? ffff81000994c000 0 4000 3031 (L-TLB) ffff810004acbf18 0000000000000046 ffff810001203140 ffff810001203140 ffff810001203140 ffff810009fe4000 ffff810009886000 ffff810009fe4268 000000000dd783b8 ffffffff81097e6d ffff810001203140 0000000000000287 Call Trace: [<ffffffff81097e6d>] __slab_free+0x2c5/0x2f9 [<ffffffff8103829b>] do_exit+0x839/0x83d [<ffffffff81038321>] sys_exit_group+0x0/0xe [<ffffffff81009d2e>] tracesys+0xd5/0xda
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
I do not recall seeing such crash for a while.