Strange X behaviour reporting root window ID on an Enter/LeaveNotify event
bob at lorez.org
Tue Oct 21 09:41:29 PDT 2008
I'll preface by saying I'm by no means fully versed on the X protocol,
so what I'm seeing might be valid but unintuitive.
I've been investigating an annoying bug in the xorg and metacity
packages shipped with Fedora 9. Part of this bug was pseudo-fixed in
Metacity shipping in Fedora 10. I have a triple-head Xinerama setup,
running the Metacity window manager.
The problem is that when Metacity starts up, it queries the X server for
the root window ID by storing the return of RootWindow. Some unreliably
reproducible series of events eventually causes X to send an EnterNotify
event to Metacity, but with a root window ID that differs from the one
queried at startup. This causes F9 Metacity to enter a segfault loop.
The reason is because Metacity is trying to find its own internal
"Screen" state data by this ID, and the function that finds it returns
NULL, and is then immediately dereferenced. When Metacity is restarted
by the session manager, it gets back the same original root window ID
from RootWindow, and then receives the same EnterNotify event with the
same differing root window ID. This behaviour was fixed in the latest
Metacity by ignoring events associated with a root window ID that isn't
the one that RootWindow returned.
So with the F10 package, when this same X behaviour springs up, it stops
servicing pointer events. The Enter/LeaveNotify events have the bogus
root window ID, but oddly enough, keyboard events get the correct root
window ID. So I can alt-tab, but the mouse becomes useless.
I wasn't sure if it was valid for one X screen to have multiple root
windows, so I tried running xwininfo -id 0x3be (the bogus root window ID
of the EnterNotify event that crashes Metacity), and that immediately
crashed X. The root window ID reported by RootWindow was 0x3bc.
More information about the xorg