Bug 1051333

Summary: vnc core dump when sendkey to it
Product: Red Hat Enterprise Linux 7 Reporter: CongLi <coli>
Component: tigervncAssignee: Tim Waugh <twaugh>
Status: CLOSED CURRENTRELEASE QA Contact: Alois Mahdal <amahdal>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: coli, jscotka, juzhang, michen, rhack, shuang, xwei
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tigervnc-1.2.80-0.25.20130314svn5065.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 12:21:55 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 CongLi 2014-01-10 05:12:23 UTC
Description of problem:
vnc core dump when sendkey to it

Version-Release number of selected component (if applicable):
kernel-3.10.0-66.el7.x86_64
tigervnc-1.2.80-0.23.20130314svn5065.el7.x86_64

How reproducible:
sometimes

Steps to Reproduce:
1. Install a RHEL7 guest w/ vnc
2. vncviewer :0 
3. sendkey 'alt+ctrl+F*' 

Actual results:
vnc core dump

Expected results:
vnc works well

Additional info:
1. debug info:
(gdb) bt
#0  Fl_X::set_cursor (this=0x12e4820, image=0x0, hotx=hotx@entry=0, hoty=hoty@entry=0) at Fl_x.cxx:2453
#1  0x00007f2f078de987 in Fl_Window::cursor (this=<optimized out>, image=image@entry=0x0, hotx=hotx@entry=0, 
    hoty=hoty@entry=0) at fl_cursor.cxx:170
#2  0x000000000042aef6 in Viewport::popupContextMenu (this=0x12a94a0)
    at /usr/src/debug/tigervnc-1.2.80-20130314svn5065/vncviewer/Viewport.cxx:908
#3  0x000000000042b453 in Viewport::handle (this=0x12a94a0, event=8)
    at /usr/src/debug/tigervnc-1.2.80-20130314svn5065/vncviewer/Viewport.cxx:441
#4  0x00007f2f07881b3d in send (event=<optimized out>, to=<optimized out>, window=<optimized out>) at Fl.cxx:1104
#5  0x00007f2f078834fd in Fl::handle_ (e=<optimized out>, window=<optimized out>) at Fl.cxx:1337
#6  0x000000000042360f in DesktopWindow::fltkHandle (event=8, win=0x12abbc0)
    at /usr/src/debug/tigervnc-1.2.80-20130314svn5065/vncviewer/DesktopWindow.cxx:434
#7  0x00007f2f078d7892 in fl_handle (thisevent=...) at Fl_x.cxx:1833
#8  0x00007f2f078d863b in do_queued_events () at Fl_x.cxx:201
#9  0x00007f2f078d8b03 in fl_wait (time_to_wait=<optimized out>) at Fl_x.cxx:275
#10 0x00007f2f078830df in Fl::wait (time_to_wait=<optimized out>) at Fl.cxx:579
#11 0x0000000000420152 in main (argc=<optimized out>, argv=<optimized out>)
    at /usr/src/debug/tigervnc-1.2.80-20130314svn5065/vncviewer/vncviewer.cxx:501

2.QEMU CML:
/home/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \
    -S  \
    -name 'virt-tests-vm1'  \
    -sandbox off  \
    -M pc  \
    -nodefaults  \
    -vga cirrus  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20140110-103032-6ISznBAM,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20140110-103032-6ISznBAM,server,nowait \
    -device isa-serial,chardev=serial_id_serial0  \
    -chardev socket,id=seabioslog_id_20140110-103032-6ISznBAM,path=/tmp/seabios-20140110-103032-6ISznBAM,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20140110-103032-6ISznBAM,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/RHEL-Server-7.0-64-virtio.qcow2 \
    -device ide-hd,id=image1,drive=drive_image1,bus=ide.0,unit=0 \
    -device virtio-net-pci,mac=9a:a2:a3:a4:a5:a6,id=idINybUu,netdev=id4q7e80,bus=pci.0,addr=04  \
    -netdev tap,id=id4q7e80,vhost=on  \
    -m 2048  \
    -smp 1,maxcpus=1,cores=1,threads=1,sockets=2  \
    -cpu 'Opteron_G3' \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,media=cdrom,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/isos/linux/RHEL7.0-Server-x86_64.iso \
    -device ide-cd,id=cd1,drive=drive_cd1,bus=ide.0,unit=1 \
    -drive id=drive_unattended,if=none,snapshot=off,aio=native,media=cdrom,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/rhel70-64/ks.iso \
    -device ide-cd,id=unattended,drive=drive_unattended,bus=ide.1,unit=0 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -kernel '/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/rhel70-64/vmlinuz'  \
    -append 'ks=hd:/dev/sr1:/ks.cfg nicdelay=60 console=ttyS0,115200 console=tty0'  \
    -initrd '/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/rhel70-64/initrd.img'  \
    -vnc :0  \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=d,menu=off  \
    -no-kvm-pit-reinjection \
    -no-shutdown \
    -enable-kvm \
    -monitor stdio

Comment 4 Alois Mahdal 2014-03-10 19:51:33 UTC
(In reply to CongLi from comment #0)
> [...]

I can't reproduce this with old (1.2.80-23) version.  I tried adding two files -- as listed at the end of this comment -- to /etcX11/xorg.conf.d/, rebooting and connecting to the machine.

When I sent for example Ctrl-Alt-F3 (this is possible by using special menu in vnc viewer that can be shown with F8), console was swithched to tty3.  Of course, at this moment, machine was not usable via the vnc session, but immediately after switching it back to the graphical console via virt-manager, the same vnc session was working fine.

No crashes seen.

Many of these things could have been configured differently, though.  So do you have more specific information?


> Steps to Reproduce:
> 1. Install a RHEL7 guest w/ vnc

Did you use vnc module in X or start vncserver manually (I'd expect that to create session on :1)?  What are your settings in xorg.conf.d?


> 2. vncviewer :0 
> 3. sendkey 'alt+ctrl+F*'

What do you expect to happen?  is the behavior I escribed above expected or something else? 

~

Notes:

 *  The linked bug mentions SSH tunnel but I'm not sure it's
    necessary.  It seems to me that you have reproduced the bug
    without it.

 *  Also I'm using VGA video driver.  The default QXL is crashing this
    old version (bug 1067709).

~

/etc/X11/xorg.conf.d/10-module.conf:

Section "Module"
	Load	"vnc"
EndSection

/etc/X11/xorg.conf.d/30-screen.conf:

Section "Screen"
    Identifier "Screen0"
    DefaultDepth 24
    Subsection "Display"
       Viewport 0 0
       Depth 24
       Modes "1024x768"
    EndSubsection
    Option "SecurityTypes" "None"
EndSection

Comment 5 Tim Waugh 2014-03-11 10:06:37 UTC
Some background about the crash: it happens when the context menu (F8) is shown but before the server has told us to draw a cursor, so you might need to make sure the local cursor doesn't enter the vncviewer window area. I don't think I ever managed to reproduce this myself.

If it turns out not to be feasible to reproduce this we could always create a VNC server proxy that just filters out "draw cursor" messages.

Comment 6 CongLi 2014-03-11 10:11:47 UTC
(In reply to Alois Mahdal from comment #4)
> (In reply to CongLi from comment #0)
> > [...]
> 
> I can't reproduce this with old (1.2.80-23) version.  I tried adding two
> files -- as listed at the end of this comment -- to /etcX11/xorg.conf.d/,
> rebooting and connecting to the machine.

> When I sent for example Ctrl-Alt-F3 (this is possible by using special menu
> in vnc viewer that can be shown with F8), console was swithched to tty3.  Of
> course, at this moment, machine was not usable via the vnc session, but
> immediately after switching it back to the graphical console via
> virt-manager, the same vnc session was working fine.
> 
> No crashes seen.
> 
> Many of these things could have been configured differently, though.  So do
> you have more specific information?

1. I use 'ssh -X' to connect the host.
  The vnc works well when do 'vncviewer :0' to the guest, and guest also works well. It core dump when I send key with the following steps.  

steps:
send F8 -> select ctrl -> send F8 -> select alt -> send F*.

> > Steps to Reproduce:
> > 1. Install a RHEL7 guest w/ vnc
> 
> Did you use vnc module in X or start vncserver manually (I'd expect that to
> create session on :1)?  What are your settings in xorg.conf.d?

1. vncsever is started by qemu process.

2. # cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us"
EndSection


> > 2. vncviewer :0 
> > 3. sendkey 'alt+ctrl+F*'
> 
> What do you expect to happen?  is the behavior I escribed above expected or
> something else? 

1. open another tty on the guest.

It can be reproduced on (24):
tigervnc-1.2.80-0.24.20130314svn5065.el7.x86_64

Tested with 25 and 30, can't hit it.

> ~
> 
> Notes:
> 
>  *  The linked bug mentions SSH tunnel but I'm not sure it's
>     necessary.  It seems to me that you have reproduced the bug
>     without it.

I used 'ssh -X' to connect the host, and I will test it without ssh.
 
Thanks,
Cong

Comment 7 CongLi 2014-03-11 10:17:26 UTC
(In reply to Tim Waugh from comment #5)
> Some background about the crash: it happens when the context menu (F8) is
> shown but before the server has told us to draw a cursor, so you might need
> to make sure the local cursor doesn't enter the vncviewer window area. I
> don't think I ever managed to reproduce this myself.

Yes, When I send 'F8' to the guest, there is a viewer window popping up in the vnc window area. But not sure whether it is related, for the viewer popping up automatically.

> If it turns out not to be feasible to reproduce this we could always create
> a VNC server proxy that just filters out "draw cursor" messages.

Comment 8 CongLi 2014-03-12 06:05:29 UTC
(In reply to CongLi from comment #6)

> > Notes:
> > 
> >  *  The linked bug mentions SSH tunnel but I'm not sure it's
> >     necessary.  It seems to me that you have reproduced the bug
> >     without it.
> 
> I used 'ssh -X' to connect the host, and I will test it without ssh.

This bug can be reproduced without 'ssh'.

Thanks,
Cong

Comment 9 Ludek Smid 2014-06-13 12:21:55 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.