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 768999 - gdkscreen-x11: Don't try to calculate a refresh rate for RandR 1.5 when the XRRModeInfo doesn't have one
gdkscreen-x11: Don't try to calculate a refresh rate for RandR 1.5 when the X...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
3.21.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-07-20 15:15 UTC by Emilio Pozuelo Monfort
Modified: 2018-03-08 15:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix division by zero when calculating the refresh rate (1.05 KB, patch)
2016-07-20 15:19 UTC, Emilio Pozuelo Monfort
committed Details | Review

Description Emilio Pozuelo Monfort 2016-07-20 15:15:23 UTC
In Debian builds, we run the test suite under Xvfb as the build daemons don't have X running. This used to work fine, but 3.21.x has introduced a regression that causes a SIGFPE in gdkscreen-x11.c:

Program received signal SIGFPE, Arithmetic exception.
0x00007ffff3be3168 in init_randr15 (screen=0x628000, changed=0x7fffffffe614) at /build/gtk+3.0-3.21.4/./gdk/x11/gdkscreen-x11.c:477
477	                  refresh_rate = (1000 * xmode->dotClock) / (xmode->hTotal *xmode->vTotal);
(gdb) p *xmode
$1 = {id = 68, width = 640, height = 480, dotClock = 0, hSyncStart = 0, hSyncEnd = 0, hTotal = 0, hSkew = 0, vSyncStart = 0, vSyncEnd = 0, 
  vTotal = 0, name = 0x622140 "640x480", nameLength = 7, modeFlags = 0}


root@tatooine:/tmp/buildd/gtk+3.0-3.21.4/debian/build/shared/testsuite/gdk# xvfb-run xrandr --verbose
xrandr: Failed to get size of gamma for output screen
Screen 0: minimum 1 x 1, current 640 x 480, maximum 640 x 480
screen connected 640x480+0+0 (0x44) normal (normal) 0mm x 0mm
	Identifier: 0x46
	Timestamp:  545194463
	Subpixel:   unknown
	Clones:    
	CRTC:       0
	CRTCs:      0
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
  640x480 (0x44)  0.000MHz *current
        h: width   640 start    0 end    0 total    0 skew    0 clock   0.00KHz
        v: height  480 start    0 end    0 total    0           clock   0.00Hz
Comment 1 Emilio Pozuelo Monfort 2016-07-20 15:19:31 UTC
Created attachment 331828 [details] [review]
Fix division by zero when calculating the refresh rate

This can happen when running a GTK+ app under Xvfb.
Comment 2 Matthias Clasen 2016-07-25 12:27:31 UTC
of course, the real bug here is in X returning us nonsense
Comment 3 Michael Biebl 2016-10-01 10:17:53 UTC
I see this was committed as f44baf51d9e8616acd9b929d9cfef83a4a3ad00a but only for init_randr15().
The same code is also in init_randr13(), should the fix/workaround be applied there as well for consistencies sake?
Debian has libxrandr 1.5, but maybe there are still distros out there using older libxrandr versions
Comment 4 Matthias Clasen 2016-10-05 13:06:27 UTC
Sure, a patch would be welcome
Comment 5 Pavel Roskin 2016-12-03 02:24:41 UTC
Here's the bug for init_randr13() and the patch: #775546