Probable X bug causing Metacity to melt down
- From: Bob Richmond <bob lorez org>
- To: metacity-devel-list gnome org
- Subject: Probable X bug causing Metacity to melt down
- Date: Sat, 18 Oct 2008 03:05:45 -0000
There's an annoying bug in the Fedora 9 Metacity + Xorg packages, and
it's not fixed in F10 rawhide...
I have a triple-head Xinerama configuration. The bug presents itself
when Metacity tries to process an Enter/LeaveNotify X event whose root
window ID does not match the ID of the root window derived from
RootWindow in meta_screen_new. The Xinerama configuration is supposed to
merge all three displays into one logical "screen" with one super-wide
root window. However, under some (difficult to reliably reproduce)
circumstances, X will report events on a made-up root window ID.
In src/core/display.c, the event gets processed, and at the point in
which it tries to find the display associated with this made-up root
window ID (line 1986), meta_display_screen_for_root returns NULL, and
the pointer is soon dereferenced causing a segfault loop.
This behaviour was described and fixed here:
http://bugzilla.gnome.org/show_bug.cgi?id=422242#c7
The fix was to simply ignore events with differing root window IDs than
the one queried at startup.
I updated to the F10 rawhide Metacity because I figured the new package
would fix the problem, but when X starts making up root window IDs,
instead of Metacity going into an endless segfault loop, it stops
responding to Pointer events. Clicking and moving the pointer over
windows in focus-follows-pointer mode does nothing.
Oddly enough, keyboard events are still processed. I can type into
already-open terminal windows. But in the absence of an open window, the
only recourse is ctrl-alt-backspace.
For whatever reason, the mouse events are reported with the made-up root
window ID, while the keyboard events report the correct root window ID
in the "root" slot of the XEvent struct.
I don't think there's anything Metacity could do differently to handle
broken X events, but I wanted to at least provide insight as to why
#422242 is occurring.
Here's a verbose log snippet that demonstrates the issue:
--cut--
Window manager: Activating workspace 0
Window manager: Added screen 0 (':0.0') root 0x3bc
Window manager: Grabbing display, grab count now 1
Window manager: Grabbing display, grab count now 2
--snip--
Notice the root window ID of 0x3bc
--cut--
EVENTS: LeaveNotify on 0x3be: win: 0x3be root: 0x3be subwindow: 0x0
mode: NotifyNormal detail: NotifyInferior focus: 0 x: 1662 y: 543 serial
109812
EVENTS: EnterNotify on 0x41600046: win: 0x41600046 root: 0x3be
subwindow: 0x416000bb mode: NotifyNormal detail: NotifyVirtual focus: 0
x: 62 y: 543 serial 109812
--snip--
This is the end of the file, as Metacity segfaults after emitting the
Event log line. No other mention of made-up window 0x3be is present in
the log. If you try to flip to a VT and run xwininfo -id 0x3be, X
immediately segfaults. :)
[Date Prev][Date Next] [Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]