After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 425786 - GDK segfaults if XineramaQueryScreens fails
GDK segfaults if XineramaQueryScreens fails
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-04-03 09:06 UTC by Loïc Minier
Modified: 2007-04-03 13:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Revert to non-xinerama mode when XineramaQueryScreens returns NULL (1.15 KB, patch)
2007-04-03 09:07 UTC, Loïc Minier
committed Details | Review

Description Loïc Minier 2007-04-03 09:06:22 UTC
Hi,

Simon McVittie reported in Debian bug http://bugs.debian.org/417529:
"""
In check_xfree_xinerama in gdk/x11/gdkscreen-x11.c, a call is made to
XineramaQueryScreens(..., &screen_x11->num_monitors). On success, this
stores a number in num_monitors, and returns a pointer to that many
XineramaScreenInfo structures.

However, on failure (in the underlying X protocol: when the "number"
member of the reply is zero), XineramaQueryScreens returns NULL and does
not touch num_monitors.  check_xfree_xinerama does not detect this condition,
tries to copy monitor geometry by dereferencing the NULL pointer (since
it thinks there are still as many monitors as there were last time, as
XineramaQueryScreens hasn't modified num_monitors), and segfaults.

This can sometimes be provoked by using the X server and i810 driver from
experimental, together with the XRandR 1.2 extension. It often seems to
happen when I go from VGA-out + laptop screen to just the laptop, but isn't
completely reproducible. I don't think I've ever seen it happen in other
mode changes. I'm going to investigate the XRandR Xinerama implementation
next - it's possible that there's a brief period of time in which no screens
exist, and the XineramaQueryScreens failure is because GDK is unlucky
enough to query it at precisely the wrong time.

This could also be considered a flaw in XineramaQueryScreens, that it
should write 0 out to num_monitors if no monitors are found. Since it
doesn't appear to come with any documentation, it's anyone's guess what
the error behaviour is meant to be.

I can understand that there's not a whole lot GDK can do about the
screen apparently disappearing from under it...
"""

He provided a patch in a followup which I'll attach here.

This affects trunk/ as well.

Bye,
Comment 1 Loïc Minier 2007-04-03 09:07:39 UTC
Created attachment 85755 [details] [review]
Revert to non-xinerama mode when XineramaQueryScreens returns NULL
Comment 2 Matthias Clasen 2007-04-03 13:02:52 UTC
Sounds like a bug in the xrandr implementation if it temporarily looses all monitors, but the NULL check for monitors looks fine to commit to both branches.
Comment 3 Loïc Minier 2007-04-03 13:55:31 UTC
Committed as r17579 in trunk and r17580 in branches/gtk-2-10.

2007-04-03  Loïc Minier  <lool@dooz.org>

        * gdk/x11/gdkscreen-x11.c: (check_xfree_xinerama): Revert to
        non-xinerama mode when XineramaQueryScreens returns NULL; patch from
        Simon McVittie; #425786.