Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Xorg configured to use "vnc" module crashes when a client vncviewer exits
Version-Release number of selected component (if applicable):
tigervnc-server-module-1.1.0-5.el6_4.1
How reproducible:
Always
Steps to Reproduce:
1. Configure Xorg to use the vnc module
2. Connect via a vncviewer
3. Quit vncviewer
Actual results:
Xorg crashes:
[1614336.799] (EE) Backtrace:
[1614336.799] (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x46d196]
[1614336.799] (EE) 1: /usr/bin/Xorg (0x400000+0x72f99) [0x472f99]
[1614336.799] (EE) 2: /lib64/libpthread.so.0 (0x3509800000+0xf500) [0x350980f500]
[1614336.799] (EE) 3: /usr/lib64/libstdc++.so.6 (__cxa_allocate_exception+0x24) [0x3dbe8bb754]
[1614336.799] (EE) 4: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rdr10FdInStream25readWithTimeoutOrCallbackEPvib+0x2de) [0x7fa475246a1e]
[1614336.800] (EE) 5: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rdr10FdInStream7overrunEiib+0xcb) [0x7fa475246b4b]
[1614336.800] (EE) 6: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rfb16VNCSConnectionST15processMessagesEv+0x5f) [0x7fa47520fe6f]
[1614336.800] (EE) 7: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN14XserverDesktop13wakeupHandlerEP6fd_seti+0x11e) [0x7fa4751df1be]
[1614336.800] (EE) 8: /usr/lib64/xorg/modules/extensions/libvnc.so (0x7fa475199000+0x3da74) [0x7fa4751d6a74]
[1614336.800] (EE) 9: /usr/bin/Xorg (WakeupHandler+0x5b) [0x43b98b]
[1614336.800] (EE) 10: /usr/bin/Xorg (WaitForSomething+0x1ef) [0x46a7ef]
[1614336.800] (EE) 11: /usr/bin/Xorg (0x400000+0x37ab2) [0x437ab2]
[1614336.800] (EE) 12: /usr/bin/Xorg (0x400000+0x7d08a) [0x47d08a]
[1614336.800] (EE) 13: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x350901ecdd]
[1614336.800] (EE) 14: /usr/bin/Xorg (0x400000+0x26189) [0x426189]
[1614336.800] (EE)
[1614336.800] (EE) Segmentation fault at address 0x18
Expected results:
Xorg doesn't crash
Additional info:
You do not have to log in via a vncviwer, simply telnet'ing to the RFB port and exiting telnet without doing anything will crash Xorg
Using the previous version of the vnc module (tigervnc-server-module-1.1.0-5.el6) doesn't crash Xorg - the change between these two versions was:
* Thu Apr 25 2013 Adam Tkac <atkac redhat com> 1.1.0-5.1
- reenable GLX extension (#950708)
Bug 950708 does actually have a comment (https://bugzilla.redhat.com/show_bug.cgi?id=950708#c16) about this exact same issue with the new version - but the bug was closed regardless
After a bit of googling, I came across:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
- which isn't about tigervnc, it's about Mesa and GLX - but it does state:
"The TLS variable __glX_tls_Context is compiled with the TLS model initial-exec, which is only ment for executables. Used in shared libraries, it can break TLS usage in other shared libraries.
One example is when libGL is linked beforce libstdc++ in another library, which is then loaded via dlopen(). In this case, the TLS variables in libstdc++ aren't properly initialized, and it will segfault when trying to allocate an exception.
I think there are 2 possible solutions:
1. Do not compile with --enabgle-glx-tls
..."
This sort of sounds a plausible explanation here (libGL, libstdc++, loading extensions/modules, exceptions and segv etc)
So, I rebuilt/installed the latest tigervnc RPMs (1.1.0-5.el6_4.1) - but added the line:
--disable-glx-tls
to the configure part for the xserver (after the "--disable-docs --disable-devel-docs" line) in the spec file
Now when I telnet to the RFB port and quit - it no longer crashes X ...
I have no idea of any other consequences of disabling glx-tls ...
Created attachment 849372[details]
Patch to change "initial-exec" to "global-dynamic" under unix/xserver/
The Ubuntu Mesa bug talks about changing "initial-exec" to "global-dynamic" in the code
I tried this out by just changing every occurrence of "initial-exec" to "global-dynamic" under unix/xserver/ and rebuilt the RPMS without '--disable-glx-tls' - and this also appears to work ...
I'm guessing this might be a better 'fix' than disabling glx-tls ???
Created attachment 849421[details]
tigervnc11-rh950708.patch
I think a better fix is to use the existing upstream code, which I don't think is affected.
In other words, I think tigervnc11-rh950708.patch should be replaced by this file (attached).