LLNL is reporting that users are having trouble with this bug on RHEL7. 7.3 is the first time our supercomputer users have had RHEL7 and so this is causing workflow problems for several users.
As can be seen below there is an upstream patch that addresses the bug, can we please pull this back into RHEL7's version of gtk3?
+++ This bug was initially created as a clone of Bug #1172337 +++
Description of problem:
I have a CentOS 7 virtual machine running under KVM on my local machine running F21 with Intel Haswell-based integrated graphics. I'm connecting into the VM via "ssh -X" and running some graphical applications. For some reason, some apps run incredibly slowly under this setup. For example, if you start up gedit and start typing some characters, the whole window seems to mostly stall for 30-60 seconds at a time. Eclipse also exhibits these huge pauses.
This problem did not occur when I was using a Scientific Linux 6 VM from the Fedora host. I tested it with a Fedora 20 VM as well and it had the same issue. Strangely enough, connecting into a CentOS 7 physical machine over the network didn't seem to have this problem, the GUI was responsive.
It seems like the combination of an F20/F21 host OS, modern Gnome 3-based guest, and connecting into the guest via SSH is what causes the problem. Based on the network traffic showing up in ifconfig on the guest, during these pauses there's hardly any traffic going across the network connection, so I don't think it's just bottlenecked on network bandwidth (not that this should be an issue anyways with a local connection). My only real theory at this point is that the particular timing of the SSH connection to a local VM is somehow causing issues.
It appears that some apps are affected more than others. The problem is quite apparent with gedit and gnome-calculator. Some others like gvim, however, have hardly any issues.
Version-Release number of selected component (if applicable):
Every time (for me anyway)
Steps to Reproduce:
1. Create and start up CentOS 7 KVM virtual machine (or Fedora 20 VM also seems to work) using NAT networking
2. ssh -X into VM using its NAT IP address (192.168.122.x) and run gedit
3. Type, open files, etc. in gedit
GUI stops responding for 30-60 second intervals.
GUI responds properly.
I have no idea if the X server is the cause of the problem, or whether the issue is even in the host and not the guest OS, but I wasn't sure where else to report this.
--- Additional comment from Robert Hancock on 2014-12-11 12:22:44 EST ---
It looks like this does not only affect connections to a local VM, but connections to another real computer over the network as well. I have been able to reproduce this by running gedit over an SSH connection from two computers running F21, both of which use Intel Haswell-based integrated graphics. On another F21 machine that used Nvidia graphics with the nouveau driver, I was NOT able to reproduce the problem.
So from what I can tell this problem seems to be graphics driver dependent, though it's still possible that this is a red herring.
--- Additional comment from Robert Hancock on 2014-12-11 12:26:07 EST ---
And the CentOS 7 part was also not relevant, as F21->F21 SSH connections have the same issue.
--- Additional comment from Robert Hancock on 2014-12-19 15:28:28 EST ---
--- Additional comment from Robert Hancock on 2014-12-19 15:29:00 EST ---
--- Additional comment from Robert Hancock on 2014-12-19 15:40:31 EST ---
I've attached the output of two test cases for this. Each involves logging into a CentOS 7 machine on the network with ssh -X, then running gedit under xtrace to capture all of the X events, and typing some characters into the window. In the working case, gedit works normally. In the failing case, gedit basically stops rendering after the first key is pressed and the text window doesn't update (though it still responds to the close button).
I have no idea why it consistently works on the one machine but fails on the other. The only difference I can see is that the machine I'm logging into in the working case is a fair bit slower. The faster machine is the one where gedit doesn't work properly. There also appear to be some ordering differences between the two files: in the working one, when the program sends requests to change the window title properties after the first key is pressed (to add the star to the title), it takes 7ms to get the PropertyNotify messages back (after a bunch of other render requests have already been sent), whereas in the broken case, it only took 1ms and there are very few rendering requests sent back after that. I'm wondering if one of these timing differences is causing the problem.
It also seems to be GTK3 apps specifically which have issues. So far, it appears that gedit and virt-manager have issues, but gvim (vim-X11), which uses gtk2, seems unaffected. So I'm reassigning this to gtk3.
--- Additional comment from Robert Hancock on 2014-12-23 12:20:12 EST ---
Also reported upstream. No response there either though.
--- Additional comment from Robert Hancock on 2015-05-29 11:35:42 EDT ---
Still occurring in F22.
--- Additional comment from Robert Hancock on 2015-07-15 22:43:04 EDT ---
Said to be fixed in gtk3 git:
--- Additional comment from Michael Stahl on 2015-09-02 18:15:48 EDT ---
with current packages in Fedora 21 and Fedora 22 this now works for me:
This seems like a dupe of bug 1243646 where this was already backported into RHEL7. Unless it got broken again since then?
Thanks robert for some reason that didn't turn up in my search. I'll dig into it more carefully with the customer and see if they hit another corner case or what. I have no doubt that they are observing some problem but their RCA may have not been perfect.
OK got a bit more detail here and I should be able to reproduce the issue now. The affected users are using Xwin32 or Xquartz.
Even though bug 1243646 has been resolved. It seems like there continues to be a problem see: https://bugzilla.redhat.com/show_bug.cgi?id=1313902 they reference the original gnome gtk bug which then points back to 1243646.
*** This bug has been marked as a duplicate of bug 1313902 ***