GNOME Bugzilla – Bug 433253
Metacity crash corrupts future Gnome sessions
Last modified: 2007-09-18 03:18:32 UTC
The bug has been opened on https://bugs.launchpad.net/bugs/106350 "Binary package hint: metacity I'm not sure what's the cause of this, but I have this problem on two different HP Companc nc6320 laptops. After loging in, all saved Windows from my previous session are restored, but on top of each other and without Window manager elements (no title bar, close button, resize possibility...). The only way to get a working Gnome again, is by removing the .gnome2 folder. The problem only appeared in Feisty around 10 april on my first machine and today on the second, so I guess it's a new Feisty bug. On this machine, I've found a metacity crash report, with a timestamp from the moment I shut down the machine yesterday. I have the "save session option" on, so it might be possible that part of the crashed state is "saved" in my session or something like that. ... http://librarian.launchpad.net/7394214/session .gnome2/session file after the crash I reproduced the bug this evening. I logged in, moved the .gnome2/session file away, turned off session-saving, logged out and logged back in. Everything was back to normal then. When examining the session-file, there was no line for metacity (while there is one when everything is normal). So I think this is what happens, which prevents metacity from starting: * user presses logout * metacity crashes and stays down * gnome saves the state of the session, so without metacity running * shutdown ----> boot * user logs in * gnome reads session file without metacity-line => result = no metacity started. This bug (metacity not starting at login) should thus not happen when you don't save the state of the sessions. Remaining question is why metacity crashes :) In attachement is the .gnome2/session-file from right after the crash. ... http://librarian.launchpad.net/7402105/strace-metacity25042007.log strace of metacity crash ... http://librarian.launchpad.net/7404149/gdb-metacity.txt gdb-backtrace of metacity ...
+ Trace 130458
Thread 1 (Thread -1218820416 (LWP 6058))
The corresponding code line: " timestamp = meta_display_get_current_time_roundtrip (displays->data); "
Ooops! Yeah, this crash is my fault. I introduced it in svn revision 3137, as a "simple cleanup" to src/session.c. Basically, metacity is guaranteed to crash at session-save time whenever there are any programs running that don't support session-saving (e.g. emacs and half a zillion other old apps out there). The fix is pretty simple, so I'll mark this as a gnome-love bug.
Strange enough to be the first to give love here, after two months of idleness. I'd like to fix this finally, but I'm not sure I really know what to do. Is resetting displays to NULL really necessary? And besides, is it ok to only take timestamp from the first display, shouldn't meta_display_get_current_time_roundtrip be inside the while loop (around line 1818, as per version 2.18.5, I believe)?
Created attachment 91279 [details] [review] A quickfix, don't reset displays variable too early Almost primitive, but solves the problem in my case.
Looks good to me.
downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=243761 It looks like this never got committed? It'd be nice to get this in even though we're frozen.
Oh, crap. Yeah, Alexey's patch should go in. Could you make the freeze break request for me, Ray? (And commit the patch upon approval, and maybe even make a release this weekend if Thomas can't or I don't feel better enough?) I have bronchitis and have been out this whole past week, and I've not been up to much of anything...
I'm feeling a bit better today; I made the request to r-t just now...
Got the approval, so I went ahead and committed and released metacity-2.20.0. Thanks for the patch, Alexey!
Woops, sorry for the slow response, Elijah. I didn't check my bug mail all weekend.
Nah, no worries; I was much slower to respond to you (since I wasn't feeling well enough to check my email until several days after you emailed). I only ended up giving you less than a day to respond due to feeling much better than expected on Saturday. But, overall, that's the best outcome possible in my book anyway. :-)