Bug 246369 - gnome-session sometimes crashes on exit
Summary: gnome-session sometimes crashes on exit
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session   
(Show other bugs)
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-01 05:05 UTC by Michal Jaegermann
Modified: 2008-04-04 16:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-04 16:50:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2007-07-01 05:05:26 UTC
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):

How reproducible:
you never know

Comment 1 Michal Jaegermann 2007-07-04 19:27:57 UTC
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

Comment 2 Michal Jaegermann 2007-07-08 19:23:37 UTC
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

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

Comment 3 Bug Zapper 2008-04-04 12:53:48 UTC
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
(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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 4 Michal Jaegermann 2008-04-04 16:50:07 UTC
I do not recall seeing such crash for a while.

Note You need to log in before you can comment on or make changes to this bug.