Have you been able to similarly crash any other gtk3 application? Say gedit, nautilus, evolution, etc..

Hello Debarshi,

I have a similar crash but not sure if it's same 

~~~
Core was generated by `/usr/libexec/gnome-session-check-accelerated'.
Program terminated with signal 8, Arithmetic exception.
#0  0x00007fb8f59bf23c in init_randr13 (changed=<synthetic pointer>, screen=0xe00020) at gdkscreen-x11.c:640
640	                  refresh_rate = (1000 * xmode->dotClock) / (xmode->hTotal *xmode->vTotal);
(gdb) bt
#0  0x00007fb8f59bf23c in init_randr13 (changed=<synthetic pointer>, screen=0xe00020) at gdkscreen-x11.c:640
#1  init_multihead (screen=screen@entry=0xe00020) at gdkscreen-x11.c:841
#2  0x00007fb8f59bf908 in _gdk_x11_screen_new (display=display@entry=0xdf90e0, screen_number=0) at gdkscreen-x11.c:906
#3  0x00007fb8f59af278 in _gdk_x11_display_open (display_name=<optimized out>) at gdkdisplay-x11.c:1416
#4  0x00007fb8f5983389 in gdk_display_manager_open_display (manager=<optimized out>, name=0x0) at gdkdisplaymanager.c:472
#5  0x00007fb8f5e410da in gtk_init_check (argc=argc@entry=0x0, argv=argv@entry=0x0) at gtkmain.c:1093
#6  0x00007fb8f5e41109 in gtk_init (argc=argc@entry=0x0, argv=argv@entry=0x0) at gtkmain.c:1150
#7  0x00000000004012a0 in main (argc=<optimized out>, argv=<optimized out>) at gnome-session-check-accelerated.c:140
(gdb) list
635	          for (j = 0; j < resources->nmode; j++)
636	            {
637	              XRRModeInfo *xmode = &resources->modes[j];
638	              if (xmode->id == crtc->mode)
639	                {
640	                  refresh_rate = (1000 * xmode->dotClock) / (xmode->hTotal *xmode->vTotal);
641	                  break;
642	                }
643	            }
644	
(gdb) p xmode
$1 = (XRRModeInfo *) 0xdfd140
(gdb) p *xmode
$2 = {id = 63, width = 1920, height = 1058, dotClock = 0, hSyncStart = 0, hSyncEnd = 0, hTotal = 0, hSkew = 0, vSyncStart = 0, vSyncEnd = 0, vTotal = 0, name = 0xdfd190 "1920x1058", 
  nameLength = 9, modeFlags = 0}

~~~

in this customer's case, he is not able to access the gnome via xdmcp.

Please take a look at this and let me know if they are the same or different,

Thanks,

I guess XRRModeInfo needs to be replaced with GVariant implementation as in below patch for reference: 

https://mail.gnome.org/archives/commits-list/2013-July/msg07229.html

and IMHO bug needs to be marked against gtk3. Please check and confirm.

(In reply to Ajinkya Patil from comment #4)
> Hello Debarshi,
> 
> I have a similar crash but not sure if it's same 

Yes, it's the same crash.

(In reply to Divya from comment #5)
> I guess XRRModeInfo needs to be replaced with GVariant implementation as in
> below patch for reference: 
> 
> https://mail.gnome.org/archives/commits-list/2013-July/msg07229.html

That's slightly different. It's about abstracting X and Wayland display configuration code, which is used by Settings to set up displays, behind the same public API. Since XRandR (including XRRModeInfo) is an X API that's not present in Wayland, GnomeRR (which is part of libgnome-desktop) either needs to have separate code paths for X and Wayland or it can use something else (eg., Mutter) that already takes care of the abstraction. That patch does the latter.

This bug is about GTK+'s X backend, and since GTK+ already has different code paths for each of it's display backends, we need to fix the particular backend.

This particular bug is relatively very simple. It's just that the Windows Exceed X server doesn't advertise a refresh rate value and GTK+ isn't prepared for that.

(In reply to Piyush Bhoot from comment #0)
> This problem seems to have appeared from RHEL 7.4 (no problem with 7.3) and
> I'm able only to reproduce it with Exceed X-server in Windows.

Yes, that's because gtk3 was rebased from 3.14.x to 3.22.x in RHEL 7.4, and the display output code had some significant changes. The absence of a refresh rate from the X server isn't the end of the world - GTK+ simply falls back to 60 Hz. However, there is one place which is missing some conditional guards.

Bug 1566101 is related.

Switching to verified based on comment 23.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3140