Description of problem:

Some recent update is making every gtk3 program abort when run under x2go.
The most immediate symptom appears to be libepoxy passing a NULL pointer to
sscanf to interpret what it believes is a version string:

From virt-manager blowing up under gdb:

#0  0x00007ffff6da025f in rawmemchr () at /lib64/libc.so.6
#1  0x00007ffff6d87fe2 in _IO_str_init_static_internal () at /lib64/libc.so.6
#2  0x00007ffff6d76767 in __isoc99_vsscanf () at /lib64/libc.so.6
#3  0x00007ffff6d76707 in __isoc99_sscanf () at /lib64/libc.so.6
#4  0x00007fffdd72db35 in epoxy_glx_version () at /lib64/libepoxy.so.0

From emacs blowing up in a shell:

/lib64/libc.so.6(__rawmemchr+0x1f)[0x7f488fee625f]
/lib64/libc.so.6(+0x7afe2)[0x7f488fecdfe2]
/lib64/libc.so.6(__isoc99_vsscanf+0x57)[0x7f488febc767]
/lib64/libc.so.6(__isoc99_sscanf+0x87)[0x7f488febc707]
/lib64/libepoxy.so.0(epoxy_glx_version+0x45)[0x7f488f3a9b35]

You'll note the common theme :-).

Version-Release number of selected component (if applicable):
libepoxy-1.3.1-2.fc24.x86_64


How reproducible:
100%

Steps to Reproduce:
1.Run an x2go session
2.Run any gtk3 program under that session
3.

Actual results:
Boom.

Expected results:
Gtk3 displaying something without using GL.

Additional info:

Just looking at the libepoxy source rpm I see things like:

    version_string = glXQueryServerString(dpy, screen, GLX_VERSION);
    ret = sscanf(version_string, "%d.%d", &server_major, &server_minor);

No check for NULL version_string :-(.

I have no idea if the programs would work if they got past these calls, but
this seems to happen really early in all gtk3 programs.