GNOME Bugzilla – Bug 751335
gnome shell stops working with message "pushModal: invocation of begin_modal failed"
Last modified: 2021-07-05 14:40:53 UTC
gnome-shell periodically stops working - no response to most mouse inputs (hot corner gives animation but not change into overlay). The only indication of failure is message "Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed" on stdout. I could not find more problems in journalctl.
That means that some other application took an X11 grab. There's not much I can tell you other than to find the application that did that and figure out what's going on.
this is a known bug when using the Overview on Startup or alternate Jump to Overview extension. I was never wise enough to determine why or what we are doing wrong to cause this, but alas it happens depending on how you use the extension. Some talk can be found here, but we are both clueless: https://github.com/simonthechipmunk/jumptooverview/issues/1 i dont know if you have installed these or anything similair, but just though id mention that some weird things can make it happen...
(In reply to Jasper St. Pierre from comment #1) > That means that some other application took an X11 grab. There's not much I > can tell you other than to find the application that did that and figure out > what's going on. Hmm. - During one repro the only other application running was firefox so the options are limited. - Restart of gnome-shell (from tty1 or if gnome-temrminal had focus at the time of bug) should not fix the problem as far as I understand as the offending application would still hold the lock - but it does here. PS. I don't have any extensions installed.
Unfortunately, debugging tools on X11 are severely limited -- there is no application which can tell you who took the grab. Are you able to reproduce it often?
(In reply to Jasper St. Pierre from comment #4) > Unfortunately, debugging tools on X11 are severely limited -- there is no > application which can tell you who took the grab. Are you able to reproduce > it often? I reproduced it multiple times over the weekend but not since then. It might be due to usage patters on workdays/weekends (or amount of things I do during workdays on my own computer).
I see this in efi boot f23 Alpha RC-2 workstation x86_64 installed to HD may be related to ff google callendar pop up event alerts..? Total system freezes up have to cold boot to recover.
(In reply to Jasper St. Pierre (not reading bugmail) from comment #1) > That means that some other application took an X11 grab. There's not much I > can tell you other than to find the application that did that and figure out > what's going on. This happens to me every few days. Today it happened with Epiphany, GNOME Terminal, gedit, Boxes, and System Settings open. Surely the shell should be robust to this; applications should not be able to break the desktop....
it's a limitation of X that applications can break the desktop like that. Wayland fixes it. Anyway, I think Daniel Stone added the ability to print grab clients a while back. digging a little, what you have to do is: $ gsettings set org.gnome.desktop.input-sources xkb-options "['grab:debug']" then hit ctrl-alt-F11 and grab info will be sent to the journal. You'll still have to use xwininfo or xlsclients or something to match up the client ids.
(In reply to Ray Strode [halfline] from comment #8) > it's a limitation of X that applications can break the desktop like that. > Wayland fixes it. > > Anyway, I think Daniel Stone added the ability to print grab clients a while > back. digging a little, what you have to do is: > > $ gsettings set org.gnome.desktop.input-sources xkb-options "['grab:debug']" > > then hit ctrl-alt-F11 and grab info will be sent to the journal. You'll > still have to use xwininfo or xlsclients or something to match up the client > ids. I cannot find anything like that in journal. Any hints on what I should look for?
sorry just noticed your question a year later. The message is something like Printing all currently active device grabs: Active grab 0xc00lbad (xi2) on device 'Virtual core pointer' (2) End list of active device grabs should be in the X log.
Maciej: Is this still an issue? Or can this be closed as RESOLVED OBSOLETE?
(In reply to André Klapper from comment #11) > Maciej: Is this still an issue? Or can this be closed as RESOLVED OBSOLETE? This is still a problem and has been driving me nuts over the last month or so. I'm probably motivated enough to try and retrieve more information out of this (to help debug this) in case someone could point to me how. ------------------------------------------------------------------------------ MY THOUGHTS: If I'd have to wager a guess..: -> I'd say the bug exists in something related to Window Manager (in case that's responsible for managing window focus) -> It's probably not gnome-shell related .. because I'm running Cinnamon -> It's common to GNOME Desktop Environment and Cinnamon Desktop Environment, because the bug has been reported here .. and since the bug was reported over 4 years ago, it's probably something that's not changed in all this time AND is shared code between these two projects. ------------------------------------------------------------------------------ THE BUG: Occasionally mouse clicks stop being sent to the window that's active. They either seem to be lost/ignored, or are sent to the wrong window (which I observed by selecting text in a terminal and text was instead being selected in another terminal window). Keyboard works correctly, and can change window focus by Alt+Tab. ------------------------------------------------------------------------------ WHAT I TRIED: Running `cinnamon --replace & disown` and it didn't help. The only result was, that I was given some output, such as multiple lines of: > Cjs-Message: 12:17:06.726: JS LOG: pushModal: invocation of begin_modal failed and > (cinnamon:50760): Cjs-WARNING **: 12:27:40.742: JS ERROR: TypeError: b is null Panel.prototype._updatePanelVisibility@/usr/share/cinnamon/js/ui/panel.js:3481:44 The stupidest thing is, that after playing around without mouse for a while, the problem disappeared by itself! (about 5 to 10 minutes) ------------------------------------------------------------------------------ MY SYSTEM SPECS: Operating System: Arch Linux Kernel: Linux 4.19.89-1-lts Architecture: x86-64 local/cinnamon 4.4.4-1 local/cinnamon-desktop 4.4.1-1 local/cinnamon-session 4.4.0-1 local/cinnamon-settings-daemon 4.4.0-2 local/cjs 4.2.0-1 local/muffin 4.4.1-1
Have recently faced the same issue on Ubuntu 18.04. It occurs rather frequently, sometimes, within ten minutes. Previously, it has never occurred. Same message is printed in the logs. Upgrade to Ubuntu 20.04, which ships GNOME Shell 3.36.2, did not help. There is an immediate workaround, documented on the unix stack exchange/ Switching to login screen (Ctrl+Alt+F1) and back to the main (Ctrl+Alt+F2) helps: https://unix.stackexchange.com/questions/502315/gnome-partially-stops-responding-to-mouse-keyboard
I'm also facing this issue on Ubuntu 18.04. When I used Dmitry workaround journalctl spitted number of stack traces and asserts, but everything started to work. I'm attaching this log.
Created attachment 374289 [details] Journalctl after using Ctrl+Alt+F1
I think it might have been something wrong with my wireless mouse, because it also caused some issues with the window manager on Macs. I have a set of Microsoft keyboard and mouse, and when I used the mouse on Mac, it caused some issues with highlighting of menu items. When I replaced it with a different wireless mouse (but kept the keyboard), the issue was gone. As I used the same keyboard and mouse on Linux, I suspect this issue was also somehow caused by the mouse. If you face this issue, consider checking if it reproduces with a different mouse. Even if this hypothesis is correct, I wonder what can go wrong with a mouse so that it appears to work but breaks window managers on different OSes, and how to debug it. It used to work perfectly.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.