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.
Created attachment 1221160 [details] Patch to add NULL pointer checks to libepoxy Here is the patch I used to stick checks for NULL pointers in lots of places that were calling str* and sscanf routines. I can now start virt-manager and virt-viewer under an x2go session without getting a segfault.
X2Go users are seeing this on FC25 as well. Please backport upstream's fix: https://github.com/anholt/libepoxy/commit/a15a92c2cbe0a8f45a1ff6258b22957c17c7118e
This bug seems to be triggered by a MESA upgrade, check https://bugzilla.redhat.com/show_bug.cgi?id=1427174 Backporting the fix might still be worthwhile - even of MESA wasn't broken and reported a correct GLX version, instead of crashing on a NULL version.
The bug is fixed in Version 1.4.1 (stable) of libepoxy , see "https://github.com/anholt/libepoxy/releases", so maybe it's time to update libepoxy?
libepoxy-1.4.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ebc23db22
libepoxy-1.4.1-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ebc23db22
libepoxy-1.4.1-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.