GNOME Bugzilla – Bug 583870
Hamster crashes mutter
Last modified: 2009-07-31 18:14:04 UTC
Steps to reproduce: 1. Run hamster 2. Add activity 3. Crash Stack trace: I get this output in console: Bug in window manager: Set a type atom for 0x20000a4 (Hamster) that wasn't handled in recalc_window_type Other information:
Adding my original comment from the list: mutter does not crash, it aborts. I probably happens because a window type that Mutter expects to be used only for override-redirect windows is being set for a normal window; this is indeed a bug, as the EWMH only says that those properties are *typically* used for OR windows. Fixing this will need care to ensure we do not break handling of OR windows elsewhere in the codebase.
Created attachment 138182 [details] [review] Patch to allow all standard _NET_WM_WINDOW_TYPE values to be used with managed windows
Patch looks basically right to me. I wonder if that much code in the unrecognized case is really necessary - meta_window_update_net_wm_type() is already supposed to sanitize the window->type_atom field, so if we hit that code path recalc_window_type() and meta_window_update_net_wm_type() are out of sync.The old meta_bug() seems fine: if we hit something we don't recognize, it's a Mutter bug. If you go with the more verbose and non-aborting approach, I'd I think there needs to be a: meta_error_trap_push (display); [...] meta_error_trap_pop (display, TRUE); trap around the XGetAtomName - XGetAtomName fails with BadAtom if the atom isn't recognized by the server. I know that we temporarily have a big error trap pushed over all of Mutter, but I don't think we should be relying on that.
Committed with addition of the error trap as a576f7a1ea98840dd3c83f011f78583c1437fba1.