Bug 1395366
| Summary: | Segfault when no GL available on X server | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Horsley <horsley1953> | ||||
| Component: | libepoxy | Assignee: | Dave Airlie <airlied> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 24 | CC: | airlied, igeorgex, ionic, ngaywood, rkudyba | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | libepoxy-1.4.1-1.fc24 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-05-18 20:58:36 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. |
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.