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 763023 - Segfault in init_randr15()
Segfault in init_randr15()
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-03-03 07:03 UTC by fiddlerwoaroof+gb
Modified: 2016-03-04 02:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A patch that fixes the problem on my computer. (507 bytes, patch)
2016-03-03 07:03 UTC, fiddlerwoaroof+gb
none Details | Review
Patch that fixes the style issues mentioned (958 bytes, patch)
2016-03-03 15:43 UTC, fiddlerwoaroof+gb
committed Details | Review

Description fiddlerwoaroof+gb 2016-03-03 07:03:20 UTC
Created attachment 322948 [details] [review]
A patch that fixes the problem on my computer.

The pointer initialized here is, in null in some circumstances (originally tested in Debian testing, with gtk+-3.18.8, repeated with git master on March-3-2016): https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkscreen-x11.c#n652

This leads to a segfault on line 657.  The problem went away when I added the line:

if (!output_info) continue;
Comment 1 Emmanuele Bassi (:ebassi) 2016-03-03 11:59:27 UTC
Review of attachment 322948 [details] [review]:

Hi, thanks for you patch!

In GNOME we usually ask for patches generated from Git commits, either using `git format-patch` or (better) `git bz`. This allows us to easily apply the patch, and maintain the authorship information.

Could you please resubmit your patch conforming to that requirement, while you fix the issue below? Thanks again!

::: gdk/x11/gdkscreen-x11.c
@@ +654,3 @@
+
+      if (!output_info)
+        continue;

Coding style: you should not mix declarations with statements.

Also, you should use an explicit NULL comparison, i.e.

  if (output == NULL)
    continue;
Comment 2 fiddlerwoaroof+gb 2016-03-03 15:42:39 UTC
Hi, thanks for the comments.  I've fixed the issues you pointed out in this patch.

Also, I'm not sure if it matters, but the surrounding lines !ptr to check for NULL, so I wrote my patch to fit into the context: should I submit a second patch that fixes other NULL checks?
Comment 3 fiddlerwoaroof+gb 2016-03-03 15:43:21 UTC
Created attachment 322989 [details] [review]
Patch that fixes the style issues mentioned
Comment 4 Matthias Clasen 2016-03-03 18:22:00 UTC
Review of attachment 322989 [details] [review]:

I don't think XRRGetOutputInfo can legitimately return NULL.
But better safe than sorry.
Comment 5 Matthias Clasen 2016-03-03 18:23:15 UTC
Review of attachment 322989 [details] [review]:

It would be good to be a bit more specific in the commit message: what are the 'certain circumstances' ? A particular driver or X version you're seeing this with ?
Comment 6 fiddlerwoaroof+gb 2016-03-03 18:26:27 UTC
I think it's related to using two graphics cards to drive three monitors.  I'm running Debian testing (xserver-xorg 1:7.7+13) and it does, in fact, return NULL.

FWIW, I suspect that this is related to another bug in Xorg that causes Xrandr and Xinerama to return different information about the resolution of the attached monitors.