Bug 1040430

Summary: Gnome3 freezes in in vnc viewer and when vncviewer is running
Product: Red Hat Enterprise Linux 7 Reporter: Tony Camuso <tcamuso>
Component: gnome-shellAssignee: Florian Müllner <fmuellner>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: fmuellner, jkejda, lzachar, mclasen, ohudlick, riehecky, rstrode, tcamuso, twaugh
Target Milestone: pre-dev-freezeKeywords: TestBlocker
Target Release: 7.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-11 14:40:24 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:

Description Tony Camuso 2013-12-11 12:24:52 UTC
Description of problem:
Gnome3 hangs and crashes when using vnc

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


How reproducible:
So far, every time.

Steps to Reproduce:
1. Start vncserver
2. Start a vncviewer session on a remote system
3. 

Actual results:
vncviewer hangs afer a few minutes. Sometimes, Gnome3 will crash on the server side. Have to restart X to get Gnome3 back.

Expected results:
vncviewer session on remote system should operate without hanging.



Additional info:

Comment 2 Lukáš Zachar 2013-12-18 16:14:03 UTC
Same issue - after 7 minutes of running vnc session it stopped responding.
Resize of the vncviewer window make the window black.

I've only edited /usr/lib/systemd/system/vncserver@.service as hinted in the comments inside (copied & renamed, changed <USER>)

Bboth vncserver and vncviewer were run un the same machine.

Version-Release number of selected component (if applicable):
tigervnc-server-1.2.80-0.20.20130314svn5065.el7.x86_64
gnome-shell-3.8.4-14.el7.x86_64

Comment 4 Ray Strode [halfline] 2014-01-06 19:43:59 UTC
can you get a stack trace from the crash?

will probably need to try to reproduce myself to fix this one.

Comment 5 Tony Camuso 2014-01-21 13:31:41 UTC
Some more data ...

I created a virtual RHEL7 guest with Cirrus graphics emulation and was able to reproduce the hang. In fact, the entire graphics engine seemed to be wedged, because the virtual graphics head was also wedged. On the bare metal, the graphics engine would occasionally crash.

However, when I created a virtual RHEL7 guest with generic VGA emulation, I was unable to reproduce the VNC hang. However a weird thing happens when the screensaver activates in the vnc session. You cannot log back into the vnc session, because the "Unlock" button appears to be continually pressed and "Authentication Error" continuously flasshes correspondingly. 

The bare metal RHEL7 system that exhibits the hang is using nVidia GeForce 8400 GS.

VNC is not working well with RHEL7.

I do not see any of these problems with F20.

Comment 6 Matthias Clasen 2014-02-11 18:16:05 UTC
ccing the tigervnc maintainer

Comment 7 Matthias Clasen 2014-02-11 18:17:39 UTC
Comments from Owen Taylor:

<owen> Certainly not an obvious problem - probably investigation woudl require starting with rebuilding the Xvnc packages for f20 for rhel7 and seeing if they work, 
<owen> (ie.. tigervnc)
<mclasen_> ok
<mclasen_> at least it is fairly easy to reproduce - start vncserver, connect, wait a few minutes
<owen> tigervnc has an upstream bump from 1.2.8 to 1.3.0 so can't just look for relevant patches
<mclasen_> so you think the source of the problem is on the vnc side ?
<mclasen_> or rather, the fix is to be found there, I guess
<mclasen_> in the f19-f20 delta
<owen> Yes. THere's very little that gnome-shell can do to create driver specific problems
<owen> As far as gnome-shell is concerned, Xvnc should look just about exactly the same as an other llvmpipe based sess

Comment 8 Tim Waugh 2014-02-12 11:42:58 UTC
Quite possibly fixed already as a side effect of the fix for bug #1039126.

Comment 9 Matthias Clasen 2014-02-12 12:51:15 UTC
I could reproduce the hang after a few minutes easily with a nightly install from late January / early February. So, I'm afraid that it is still around.

Comment 10 Tim Waugh 2014-02-14 17:44:58 UTC
I've been trying to reproduce this with tigervnc-server-1.2.80-0.27.20130314svn5065.el7.x86_64 from RHEL7.0-20140206.0 but I haven't been able to yet. I left until the lock screen kicked in, and the session was still working (aside from some 'Failed to fork' errors which I've not investigated yet).

In case it would make a difference (not expected to) I tried with the VM's graphics set to QXL and to Cirrus.

In my tests I started the vncserver from the command line using "vncserver :1" (in an ssh session for the user). Next I'll try the systemd service method.

Comment 11 Tim Waugh 2014-02-14 19:01:00 UTC
With the systemd service, the session seems fine aside from bug #1055960.

Could you please confirm the n-v-r that you see the problem with?

Comment 12 Matthias Clasen 2014-02-17 15:25:30 UTC
The version I have here is tigervnc-1.2.80-0.28.20130314svn5065.el7.x86_64
And here is what I am doing:
- on a bare metal install
- in a local GNOME session
- open gnome-terminal
- run vncserver :1 in one tab
- run vncviewer :1 in another
- interact with the opened window just fine for a while
- come back after a few minutes
- find it not reacting to clicks anymore

Comment 13 Tim Waugh 2014-02-17 17:04:50 UTC
Does ~/.vnc/*.log show anything interesting?

Is Xvnc using much CPU?

Does 'netstat -nt' show outstanding Recv/Send-Q for the connection on port 5901?

If you close the vncviewer window and start 'vncviewer :1' again, are you able to interact with the session again?

I've tried the sequence from comment #12 but in a VM instead of bare metal, and everything is working fine. :-/

Comment 14 Matthias Clasen 2014-02-17 21:59:41 UTC
I'll get you those logs tomorrow morning - left the rhel7 machine in the office

Comment 15 Matthias Clasen 2014-02-18 13:11:09 UTC
I'm having a suspicion - maybe this is related to the problem we have where screen locking does not work under vnc - maybe my session simply got locked, and things go back. Having to wait a few minutes for the problem to occur would be plausible for that scenario.

Trying to reproduce it this morning, the vnc session locks and unlocks just fine :-(

Comment 16 Matthias Clasen 2014-02-18 14:28:36 UTC
In fact, I'm failing to reproduce this lockup entirely now. Tried vncserver outside the session, with no gdm running, and couldn't get it to lock up either.

Comment 17 Matthias Clasen 2014-02-18 14:29:29 UTC
Tony, can you still reproduce this with the current tree ?

Comment 18 Ray Strode [halfline] 2014-02-21 19:50:18 UTC
how about you Lukas?

Comment 19 Lukáš Zachar 2014-02-24 10:11:13 UTC
Great, I am not able to reproduce the problem any more.
NVRs:  
gnome-shell-3.8.4-24.el7.x86_64
tigervnc-server-1.2.80-0.28.20130314svn5065.el7.x86_64

Comment 20 Tony Camuso 2014-02-24 16:01:21 UTC
(In reply to Matthias Clasen from comment #17)
> Tony, can you still reproduce this with the current tree ?

Which tree? Gnome Desktop Environment? VNC? Kernel?

Comment 22 Martin 2014-04-29 14:42:28 UTC
gnome-shell still uses lot of CPU and sometimes crashes.