Bug 820443 - tigervnc-server-module crashes with dual screen setup
tigervnc-server-module crashes with dual screen setup
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: tigervnc (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2012-05-09 19:40 EDT by John Newbigin
Modified: 2014-10-23 10:28 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-10-23 10:28:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Newbigin 2012-05-09 19:40:55 EDT
Description of problem:
tigervnc-server-module crashes with dual screen setup

Version-Release number of selected component (if applicable):

How reproducible:
Most of the time

Steps to Reproduce:
1. Configure X with 2 screens :0.0 and :0.1
2. Configure X to load vnc for each screen
3. vnc to port 5900 and log in
4. vnc to port 6900 and move the mouse

Actual results:
X crashes

Expected results:
Should work

Additional info:
[498010.088] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x46a688]
[498010.088] 1: /usr/bin/Xorg (0x400000+0x68b59) [0x468b59]
[498010.088] 2: /lib64/libpthread.so.0 (0x31cee00000+0xf4a0) [0x31cee0f4a0]
[498010.088] 3: /usr/bin/Xorg (IsMaster+0x0) [0x44bac0]
[498010.088] 4: /usr/bin/Xorg (miPointerGetScreen+0x9) [0x458659]
[498010.088] 5: /usr/bin/Xorg (GetPointerEvents+0x5c) [0x4a82ec]
[498010.088] 6: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN11InputDevice11PointerMoveERKN3rfb5PointE+0x9a) [0x7f197e0b9a2a]
[498010.088] 7: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN14XserverDesktop12pointerEventERKN3rfb5PointEi+0x1f) [0x7f197e0b70bf]
[498010.088] 8: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rfb10SMsgReader16readPointerEventEv+0x12b) [0x7f197e0d367b]
[498010.088] 9: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rfb16VNCSConnectionST15processMessagesEv+0x38) [0x7f197e0e8128]
[498010.088] 10: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN14XserverDesktop13wakeupHandlerEP6fd_seti+0x11e) [0x7f197e0b730e]
[498010.088] 11: /usr/lib64/xorg/modules/extensions/libvnc.so (0x7f197e07a000+0x34b94) [0x7f197e0aeb94]
[498010.088] 12: /usr/bin/Xorg (WakeupHandler+0x4b) [0x44acbb]
[498010.088] 13: /usr/bin/Xorg (WaitForSomething+0x1ef) [0x45efdf]
[498010.088] 14: /usr/bin/Xorg (0x400000+0x31df2) [0x431df2]
[498010.088] 15: /usr/bin/Xorg (0x400000+0x21ebb) [0x421ebb]
[498010.088] 16: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x31ce21ecdd]
[498010.088] 17: /usr/bin/Xorg (0x400000+0x21a49) [0x421a49]
[498010.088] Segmentation fault at address (nil)
Fatal server error:
[498010.088] Caught signal 11 (Segmentation fault). Server aborting

It may also be related that if you connect to port 6900 before you connect to 5900, the mouse moves on display 0.0 and not 0.1. This does not cause a crash though.
Comment 2 Calvin Webster 2012-08-14 18:00:45 EDT
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:

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.


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)
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:

Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
Section "Module"
        Load  "record"
        Load  "fglrx"
        Load  "extmod"
        Load  "vnc"
        Load  "dri"
        Load  "dbe"
        Load  "dri2"
Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        Option "SecurityTypes" "VncAuth"
        Option "UserPasswdVerifier" "VncAuth"
        Option "PasswordFile" "/root/.vnc/passwd"

## Dual-head:

Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "aticonfig-Screen[0]-0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
Section "Module"
        Load  "glx"
        Load  "vnc"
        Load  "record"
        Load  "dbe"
        Load  "dri2"
        Load  "extmod"
        Load  "dri"
Section "Screen"
        Identifier "aticonfig-Screen[0]-0"
        Device     "aticonfig-Device[0]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Virtual   3200 3200
                Depth     24
        Option "SecurityTypes" "VncAuth"
        Option "UserPasswdVerifier" "VncAuth"
        Option "PasswordFile" "/root/.vnc/passwd"

Please let me know if you need the abrt bug report or any other information.
Comment 3 John Newbigin 2012-08-15 20:57:22 EDT
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 ?? ()
Comment 4 Calvin Webster 2012-08-16 12:29:36 EDT
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.
Comment 5 RHEL Product and Program Management 2012-09-07 01:38:18 EDT
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.
Comment 7 Tim Waugh 2014-05-23 08:33:36 EDT
Does this problem still occur with tigervnc-1.1.0-8.el6_5?


Note You need to log in before you can comment on or make changes to this bug.