Bug 820443
Summary: | tigervnc-server-module crashes with dual screen setup | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | John Newbigin <jn> |
Component: | tigervnc | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | qe-baseos-daemons |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.4 | CC: | cwebster, jos, mad, perobins, sardella |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-10-23 14:28:58 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: |
Description
John Newbigin
2012-05-09 23:40:55 UTC
This appears to be the same issue we have been having. I can confirm this behavior on EL 6.3 x86_64 architecture for a single-head display. I can confirm normal behavior on EL 6.2 x86_64 architecture for a dual-head display. I can also confirm a fix (see below) for EL 6.3 x86_64 architecture on a single-head display that I believe will work on any architecture or display configuration. I will confirm in a future comment the emergence of this problem on the EL 6.2 dual-head system (used for confirmation of normal operation) after updating to EL 6.3. I will also confirm whether the rebuilt RPM resolved the issue. [Problem Description] Connecting to the native display of a remote EL 6.3 server that is configured to use the tigervnc X server vnc module in Xorg.conf fails as soon as mouse movement is detected within the vncviewer window on the client machine. Failure does not occur until the mouse pointer moves within the boundaries of the client vncviewer window. The problem appears to be in the tigervnc-server-module RPM (tigervnc-server-module-1.0.90-0.17.20110314svn4359.el6.x86_64.rpm) from the base EL 6.3 installation. [How reproducible] Always for a previously configured and working Xorg server with tigervnc "vnc" module loaded. [Steps to reproduce] 1. Open vncviewer on a remote client to the console port (5900) of the EL 6.3 vnc server. 2. Observe that the normal login prompt is displayed. 3. Move the mouse pointer anywhere within the boundaries of the VNC viewer window The vncviewer window disappears. An error is raised in the terminal window in which "vncviewer" was run as well as in a pop-up window: ---------------------------------------------- read: Connection reset by peer (104) ---------------------------------------------- A core dump is generated and bug report created: /var/log/messages ---------------------------------------------- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected ---------------------------------------------- [Expected Results] Connections made from the same client, using the same method, to an equivalently configured EL 6.2 vnc server do not result in connection reset or core dump. Normal connections and resulting X sessions occur. [Fix] Rebuilding the tigervnc the source rpm (tigervnc-1.0.90-0.17.20110314svn4359.el6.src.rpm) produces a working tigervnc-server-module package that does not suffer from this bug. (assuming a working rpmbuild environment and build dependencies) # As normal user: cd ~/Downloads wget http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/tigervnc-1.0.90-0.17.20110314svn4359.el6.src.rpm rpm -iv tigervnc-1.0.90-0.17.20110314svn4359.el6.src.rpm cd ~/rpmbuild rpmbuild -ba SPECS/tigervnc.spec # As root: yum remove tigervnc-server-module yum localinstall /home/normal_user/rpmbuild/RPMS/x86_64/tigervnc-server-module-1.0.90-0.17.20110314svn4359.el6.x86_64.rpm Log out of X session on native (physical) console (reloads X) -or- init 3 init 5 Note: Swapping run levels hangs the display on our dual-head system, possibly due to the proprietary display driver, so a restart may be required. [Additional Information] We use "VNC Auth" connections to the native console. See below for relevant excerpts from our single and dual head machines. The VNC authentication options are placed at the bottom of the "Screen" section that is defined in the "ServerLayout" section for single-head or multi-head systems. Note: The presence of an ellipsis indicates irrelevant information that has been omitted for clarity. ## Single-head: /etc/X11/xorg.conf ------------------ Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection ... Section "Module" Load "record" Load "fglrx" Load "extmod" Load "vnc" Load "dri" Load "dbe" Load "dri2" EndSection ... Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" ... Option "SecurityTypes" "VncAuth" Option "UserPasswdVerifier" "VncAuth" Option "PasswordFile" "/root/.vnc/passwd" EndSection ------------------ ## Dual-head: /etc/X11/xorg.conf ------------------ Section "ServerLayout" Identifier "X.org Configured" Screen 0 "aticonfig-Screen[0]-0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection ... Section "Module" Load "glx" Load "vnc" Load "record" Load "dbe" Load "dri2" Load "extmod" Load "dri" EndSection ... Section "Screen" Identifier "aticonfig-Screen[0]-0" Device "aticonfig-Device[0]-0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Virtual 3200 3200 Depth 24 EndSubSection Option "SecurityTypes" "VncAuth" Option "UserPasswdVerifier" "VncAuth" Option "PasswordFile" "/root/.vnc/passwd" EndSection ... ------------------ Please let me know if you need the abrt bug report or any other information. On 6.3 with a single display setup, I get a crash every time as soon as the mouse moves. Program received signal SIGABRT, Aborted. 0x0000003a01c328a5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0000003a01c328a5 in raise () from /lib64/libc.so.6 #1 0x0000003a01c34085 in abort () from /lib64/libc.so.6 #2 0x0000003a01c6fa97 in __libc_message () from /lib64/libc.so.6 #3 0x0000003a01d01307 in __fortify_fail () from /lib64/libc.so.6 #4 0x0000003a01d012d0 in __stack_chk_fail () from /lib64/libc.so.6 #5 0x00007f47e59fdacb in InputDevice::PointerMove(rfb::Point const&) () from /usr/lib64/xorg/modules/extensions/libvnc.so #6 0x0000000000000000 in ?? () I can confirm the same faulty behavior outlined in comment #2 above for our dual-head systems after updating from EL 6.2 to 6.3. In addition, the dual-head system completely froze up after the remote vncviewer attempted the connection. The keyboard, mouse, and video were completely unresponsive and the machine would not respond to ping over the network. A cold (power-off) reboot was required to regain control. To verify consistent behavior, after reboot another attempt was made to connect remotely and again the system froze. After another cold reboot, I installed the same locally rebuilt tigervnc-server-module from the unmodified SRPM that was installed on the single-head test machines above. The problem disappeared and system now behaves normally. Remote vncviewer connections to the native console operate normally and there are no abnormal symptoms on the vncserver host or vncviewer client. If the package maintainer/developer thinks it will be helpful I would be happy to install whatever debuginfo packages you need and reproduce the faulty behavior. I can then attach the core dump to this bug. However, because the malfunction freezes this dual-head system, there will only be the core dump. All other abrt are empty following cold reboot after system freeze. Also, we're using proprietary "ATI FirePro 2270" drivers so parts of the core dump may not be useful. Please let me know if there is anything else I can do to help isolate this malfunction. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux. Does this problem still occur with tigervnc-1.1.0-8.el6_5? https://rhn.redhat.com/errata/RHBA-2014-0125.html |