Bug 1051333
Summary: | vnc core dump when sendkey to it | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | CongLi <coli> |
Component: | tigervnc | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Alois Mahdal <amahdal> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | coli, jscotka, juzhang, michen, rhack, shuang, xwei |
Target Milestone: | rc | Keywords: | 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
(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 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. (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 (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. (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 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. |