GNOME Bugzilla – Bug 453022
metacity crashed with signal 5 in g_logv()
Last modified: 2008-07-13 04:08:16 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/123451 "Binary package hint: metacity I was using openoffice writer, opened the save as dialog, closed it, pressed the close window (X) button. ProblemType: Crash Architecture: i386 Date: Sun Jul 1 18:44:09 2007 DistroRelease: Ubuntu 7.10 ExecutablePath: /usr/bin/metacity NonfreeKernelModules: cdrom Package: metacity 1:2.19.21-0ubuntu1 ... .
+ Trace 145190
Thread 1 (process 5467)
So what happened here was: * Something, presumably, OpenOffice, attempted to do a ConfigureRequest. * ("disable workarounds" was on and "raise on click" was off) * We have a policy of ignoring ConfigureRequests when they are older than the most recent timestamp on the active window, *AND* they are for a window which isn't the same application/"group" as the active window. * We therefore need to find out the group of both the active and requested windows (using meta_window_same_application()). * One of these had a null group. meta_window_get_group() will die on assertion failure if the window in question has a null group. So the possible solutions are: 1) Make meta_window_same_application() check whether either or both have NULL groups, and act accordingly; 2) Remove the check for null groups in meta_window_get_group(). The check means that MWGG cannot return null, but amusingly, in most of the places where MWGG is called, we actually do check the result against null. The extra check was added by readams in r1236 back in 2003 "to ensure robustness": http://svn.gnome.org/viewcvs/metacity?view=revision&revision=1236 I think this assertion is unnecessary and in fact causes errors. MWGG used to call meta_window_compute_group() instead, which is now only called on window creation or if the group leader changes. Is that enough? I mean, I hope it is, because it's currently all we do. If I remove the assertion but don't attempt to re-calculate the group if I find that window->group is null, I'm thinking that that's because there's no group rather than because we just didn't know it. If there *had* been a group, we would have known about it on window creation or on group leader changing. So what I'll do, unless anyone complains or has a better idea, is simply get rid of the assertion in meta_window_get_group().
Sounds good to me. :-) [I guess it does leave one corner-case where two windows don't have a group; in such a case, they probably should not be considered part of the same application despite both being in the "NULL" group, but that would only happen if both the configure-request'ed window and the active window were being withdrawn, right? I can't think of a reason why we'd care about this case, though if we wanted to be paranoid we could check for it in meta_window_same_application]
Good idea. Fixed. http://svn.gnome.org/viewvc/metacity?view=revision&revision=3785