GNOME Bugzilla – Bug 755696
Gnome Shell stops responding when multiple windows opened
Last modified: 2019-02-27 20:05:00 UTC
Tested on Fedora 23 and Rawhide, Gnome 3.18: gnome-shell-3.18.0-1.fc24.x86_64 gdm-3.18.0-1.fc24.x86_64 Also present in older versions going back at least a year. Upon booting the machine and logging in, I am able to open a single window/application and work normally. Opening a second application and attempting to change focus between the two will almost invariably result in gnome-shell ceasing to respond to mouse and (most) keyboard input. The two running applications mostly continue to function normally, although some mouse input is impaired (clicking some UI elements does nothing, it is impossible to drag windows or change focus with the mouse). When I say "most keyboard input", it is still possible to switch window focus using Alt-Tab and Alt-`, and when you do this the mouse works within the newly focused window. However no other shell functionality works, Super-key, Alt-F2 etc are all non functional. It is also impossible to click the top bar or any tray icons. Curiously, it is possible to avoid this bug by immediately logging out and back in again upon first boot, the shell then functions normally until the machine is next rebooted. Please let me know if there is any further information I can provide . I'm unfamiliar with the inner workings of the Gnome stack, so I suspected this was the right component to file against. Please correct if I was wrong!
For reference, downstream RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1224579
(In reply to Richard Bradfield from comment #1) > For reference, downstream RHBZ: > https://bugzilla.redhat.com/show_bug.cgi?id=1224579 Correction, wrong bug URL in my clipboard: https://bugzilla.redhat.com/show_bug.cgi?id=1266762
Seems like we have a stuck grab. First step is identifying which process is holding it. Using gnome-tweak-tool or gsettings/dconf-editor, add the "grab:debug" xkb option (aka "Allow grab and window tree logging" under gnome-tweak-tool > Typing > "Miscellaneous compatibility options") . Then, when you get into the stuck grab state, press Ctrl+Alt+F11. The X server will write out which process is holding the grab to its log which ends up in journalctl so please grab that output and attach it here. There might be other clues about the grab in the log too (e.g. a gnome-shell JS stack trace).
One stuck grab, gnome-terminal seems to be the culprit, would make sense as that's one program I almost always have running: Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: (II) Printing all currently active device grabs: Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: Active grab 0x1c00000 (xi2) on device 'Virtual core pointer' (2): Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: client pid 3588 /usr/libexec/gnome-terminal-server Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: at 221617 (from passive grab) (implicit) (device thawed, state 1) Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: xi2 event mask for device 2: 0xfc71c0 Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: passive grab type 4, detail 0x0, activating key 0 Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: owner-events false, kb 1 ptr 1, confine 0, cursor 0x0 Sep 29 20:11:51 fedora-workstation /usr/libexec/gdm-x-session[2946]: (II) End list of active device grabs
I'll move this over to gnome-terminal then.
g-t and vte don't use any grabs themselves; the only git grep results for 'grab' are gtk_widget_grab_focus(). So it's either gtk or the shell -> back to you for further triage
Richard, are you able to reproduce this in a newly created user account? Do you use any gnome-shell extensions? If you do can you reproduce after disabling them?
Rui, working from those suggestions, I think I've narrowed down where the grab originates. I added a new user, and I _did not_ see the issue, but when I removed the test user again it appeared again. It turns out, the stuck grab seems to happen if I **do not use the mouse** at the login screen. So when I had the second user, I clicked them on the GDM login screen to login. Whereas my normal workflow when I boot the machine is <Enter>Password<Enter>, never clicking on anything. If, when I reboot, I intentionally use the mouse, say clicking the calendar bar widget, or the language menu at the top, the issue doesn't manifest once I login. No extensions enabled.
Can you try login in with the empty user using only the keyboard? (You can use Tab to select things on the login screen)
Gave it a try, I can reproduce the bug with the brand new user by logging in without clicking anything.
And the grab debug keybinding still prints gnome-terminal-server as the grab holder?
Not always no, it is only one of several possible culprits/victims of the sticky grab. I have attached a log file with three different stuck apps, I don't doubt I could trigger it on others too.
Created attachment 312432 [details] Different stuck grabs
Can you try switching to a different input device? (a different mouse if you are using a mouse, to a mouse if you are using a touchpad) The most likely cause for this type of problem, off the top of my head, is if there is a bad event stream with mouse presses and releases not paired up properly. It might be a bug in the input stack somewhere, but since most people are not seeing this problem, it's probably specific to something with your hardware.
I just tried with a different mouse, and it seems like it was indeed hardware specific. I can't reproduce it with the only other pointing device I have. Is there anything I can do to narrow down exactly what is going wrong with my normal mouse?
(In reply to Richard Bradfield from comment #15) > I just tried with a different mouse, and it seems like it was indeed > hardware specific. > > I can't reproduce it with the only other pointing device I have. > > Is there anything I can do to narrow down exactly what is going wrong with > my normal mouse? events can be dumped at the X level with the 'xev' utility, or at the evdev level with the 'evtest utility. I think the next thing to try is to see with either of those routes whether you can reproduce unpaired events, and if there's something specific that does it - clicking quickly, clicking slowly, clicking multiple times in a row, etc. (evtest probably would need to be run from a VT so that X does't' interfere.) If you can with evtest, then that would mean that the problem is at the hardware or kernel driver level - if evtest is fine, but xev shows problems, then there would be an X or libinput issue.
I've already tested with xev in the past, mouseclicks weren't appearing while keyboard input was fine, I'll look into evtest at some point.
(In reply to Richard Bradfield from comment #17) > I've already tested with xev in the past, mouseclicks weren't appearing > while keyboard input was fine, I'll look into evtest at some point. I'm not asking about the broken state ... I'm asking about the "OK" state / or how the OK state transitions into the broken state.
I do have the same issue according to the description. I recently change my mouse for a Logitech Performance MX. Since then, I do experience this issue. Here output of ctrl+Alt+F11: Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: (II) Printing all currently active device grabs: Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: Active grab 0x5600000 (core) on device 'Virtual core pointer' (2): Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: client pid 7113 xchat Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: at 5634683 (from passive grab) (implicit) (device thawed, state 1) Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: core event mask 0x63807f Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: passive grab type 4, detail 0x0, activating key 0 Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: owner-events false, kb 1 ptr 1, confine 0, cursor 0x0 Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: Active grab 0x3200000 (xi2) on device 'Logitech Unifying Device. Wireless PID:101a' (18): Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: client pid 5725 /opt/google/chrome/chrome Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: at 5627397 (from passive grab) (implicit) (device thawed, state 1) Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: xi2 event mask for device 18: 0x7001c0 Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: xi2 event mask for device 18: 0x80700 Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: passive grab type 4, detail 0x0, activating key 0 Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: owner-events false, kb 1 ptr 1, confine 0, cursor 0x0 Feb 2 10:48:46 ikus060-t530 gdm-Xorg-:0[3257]: (II) End list of active device grabs I didn't find a clear way to reproduce it. May anyone provide me some help to narrow it down ? May I enabled trace log of events ? To workarround this issue, I unplug-plug the dongle. It seams to release the grab.
Another reporter in bug 762004 says that switching from the libinput xorg driver to the older evdev driver fixes the issue. Can someone here confirm that?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!