GNOME Bugzilla – Bug 750092
Applications can freeze mutter during input events or window redraw
Last modified: 2016-02-11 13:51:41 UTC
During interaction with an application's menu the application blocks mutter. This is a small test to reproduce (be careful, it will freeze your gnome session): 1. run any gtk3 or gtk2 application from gdb, e.g. evolution or geany 2. set a breakpoint on gtk_menu_item_deselect 3. use the application menu gdb will pause the application at the breakpoint. You won't be able to interact with any applications on any desktop any more. You won't be able to use keyboard shortcuts or the gnome-shell top bar. The only thing you can still do on GUI is moving your mouse. I can reproduce this on both gnome/X and gnome/wayland. I think applications should not be able to freeze the whole desktop session by just doing something weird in their menus. It looks like there is some async operations missing.
You can also run into this issue when using VLC 2.2.x on Fedora 22 with va-api as video backend. Steps to reproduce: 1. open VLC media player 2. go to Tools → Preferences → Input/Codecs → Hardware-accelerated decoding 3. set to "VA-API video decoder via X11" or "VA-API vide decoder via DRM" Once playback starts the desktop session including mouse cursor will freeze. Only killing VLC (from tty) helps.
(In reply to Christian Stadelmann from comment #0) > During interaction with an application's menu the application blocks mutter. > This is a small test to reproduce (be careful, it will freeze your gnome > session): > > 1. run any gtk3 or gtk2 application from gdb, e.g. evolution or geany > 2. set a breakpoint on gtk_menu_item_deselect > 3. use the application menu > > gdb will pause the application at the breakpoint. You won't be able to > interact with any applications on any desktop any more. You won't be able to > use keyboard shortcuts or the gnome-shell top bar. The only thing you can > still do on GUI is moving your mouse. > > I can reproduce this on both gnome/X and gnome/wayland. > > I think applications should not be able to freeze the whole desktop session > by just doing something weird in their menus. It looks like there is some > async operations missing. This is just how X works - once an app grabs the keyboard and mouse, there's no way for another application (even a system level application like the compositor) to get access to the keyboard and mouse. Wayland does not have grabs like this, so doesn't have the same issue. (In reply to Christian Stadelmann from comment #1) > You can also run into this issue when using VLC 2.2.x on Fedora 22 with > va-api as video backend. > Steps to reproduce: > 1. open VLC media player > 2. go to Tools → Preferences → Input/Codecs → Hardware-accelerated decoding > 3. set to "VA-API video decoder via X11" or "VA-API vide decoder via DRM" > Once playback starts the desktop session including mouse cursor will freeze. > Only killing VLC (from tty) helps. If other applications continue to update what they draw on the screen, then it's also a stuck pointer or keyboard grab due to a bug in VC. I have no idea why the choice of decoder in VLC would influence it. If other applications freeze, then it's probably instead a driver bug of some sort. I doubt it's anything to do with GNOME Shell.
(In reply to Owen Taylor from comment #2) > (In reply to Christian Stadelmann from comment #0) > > […] > > I can reproduce this on both gnome/X and gnome/wayland. > > […] > > This is just how X works - once an app grabs the keyboard and mouse, there's > no way for another application (even a system level application like the > compositor) to get access to the keyboard and mouse. Wayland does not have > grabs like this, so doesn't have the same issue. Yes, wayland does have the same issue, as I wrote above. Still it is unexpected behavior. Is it a bug in X then? > > (In reply to Christian Stadelmann from comment #1) > > You can also run into this issue when using VLC 2.2.x on Fedora 22 with > > va-api as video backend. > > Steps to reproduce: > > 1. open VLC media player > > 2. go to Tools → Preferences → Input/Codecs → Hardware-accelerated decoding > > 3. set to "VA-API video decoder via X11" or "VA-API vide decoder via DRM" > > Once playback starts the desktop session including mouse cursor will freeze. > > Only killing VLC (from tty) helps. > > If other applications continue to update what they draw on the screen, then > it's also a stuck pointer or keyboard grab due to a bug in VC. I have no > idea why the choice of decoder in VLC would influence it. If other > applications freeze, then it's probably instead a driver bug of some sort. I > doubt it's anything to do with GNOME Shell. I know this is a separate bug in VLC or its underlaying graphics stack. I just wanted to show that an ordinary programming error in any GUI application can force gnome-session to freeze. This is bad not only in extreme cases (vlc) but also when e.g. icons are loaded when a UI container is displayed for the first time. When writing GUI applications it is often easier to everything in the main loop. Many actions can take more time, and since computers are (mostly) non-deterministic any action can take very long in theory. In practice you run into these issues when e.g. a traditional harddisk is accessed (delays of ~10…20ms, often accumulated to 100…500ms). I know this is bad practice, but you won't get rid of all those bugs. As long as those applications exist (they probably will forever) using them will make gnome sessions lag. This lag is bad for user experience and users will give the culprit to GNOME.
Opening huge files in eye of gnome (for example) can trigger this bug too. See bug https://bugzilla.gnome.org/show_bug.cgi?id=710789 for some example files big enough to freeze mutter for some seconds.
Another reproducer (though not quite useful to do): 1. umask 277 2. open gedit 3. save a new file from gedit
(In reply to Christian Stadelmann from comment #5) > Another reproducer (though not quite useful to do): > 1. umask 277 > 2. open gedit > 3. save a new file from gedit I can't reproduce anything with this, other than the saved file being marked as read-only by gedit... Anyway, I don't see anything actionable on this bug report. If you have a _specific_ bug to report, please open a new bug. I'm closing this since it's useless as it is.
(In reply to Christian Stadelmann from comment #0) > During interaction with an application's menu the application blocks mutter. > This is a small test to reproduce (be careful, it will freeze your gnome > session): > > 1. run any gtk3 or gtk2 application from gdb, e.g. evolution or geany > 2. set a breakpoint on gtk_menu_item_deselect > 3. use the application menu > > gdb will pause the application at the breakpoint. You won't be able to > interact with any applications on any desktop any more. You won't be able to > use keyboard shortcuts or the gnome-shell top bar. The only thing you can > still do on GUI is moving your mouse. > > I can reproduce this on both gnome/X and gnome/wayland. This issue is not present any more. (In reply to Christian Stadelmann from comment #5) > Another reproducer (though not quite useful to do): > 1. umask 277 > 2. open gedit > 3. save a new file from gedit I guess I should have been more specific: 0. log in into a gnome/wayland session 1. open a terminal 2. run `umask 277` 3. Make sure that it is not running already 4. run `gedit` from the same terminal 5. save a new file from gedit (In reply to Rui Matos from comment #6) > Anyway, I don't see anything actionable on this bug report. If you have a > _specific_ bug to report, please open a new bug. I'm closing this since it's > useless as it is. Can you please be more specific on that? Why is this bug report useless? (In reply to Christian Stadelmann from comment #0) > I think applications should not be able to freeze the whole desktop session > by just doing something weird in their menus. It looks like there is some > async operations missing. If you are really sure this behaviour is intended and unproblematic, you can close this issue. If not, it should remain open. This sentence is the core of this bug report, not the reproducers I listed here.
(In reply to Christian Stadelmann from comment #7) > (In reply to Christian Stadelmann from comment #0) > > I think applications should not be able to freeze the whole desktop session > > by just doing something weird in their menus. It looks like there is some > > async operations missing. > > If you are really sure this behaviour is intended and unproblematic, you can > close this issue. If not, it should remain open. This sentence is the core > of this bug report, not the reproducers I listed here. Under X, as explained above, there's no work around input grabs. The X server must obey them since that's how the protocol is specified. There's absolutely nothing we can do, short of patching the X server making it non-compliant. Obviously won't happen and it doesn't fall under the GNOME project's remit anyway. As a wayland compositor, the protocol doesn't allow this, so in theory it can't happen. Now, it's possible that there's a _specific_ bug where it does happen and in that case we're interested in fixing it of course. Note that the bug might not actually be in GNOME but instead on the graphics driver or the input stack, etc. Your gedit reproducer still doesn't do anything I'd consider buggy here. What happens when you do it?
After following these steps > 0. log in into a gnome/wayland session > 1. open a terminal > 2. run `umask 277` > 3. Make sure that it is not running already > 4. run `gedit` from the same terminal > 5. save a new file from gedit My gnome session completely locks up. I cannot use mouse or keyboard any more, only sysrq keys work (barely). It's the same as noted above in previous comments and bug description: The whole desktop session freezes and is completely unusable. The reason why I reported this bug is that I think a single application should not be able to do so, especially not erroneous.
(In reply to Christian Stadelmann from comment #9) > My gnome session completely locks up. I cannot use mouse or keyboard any > more, only sysrq keys work (barely). It's the same as noted above in > previous comments and bug description: The whole desktop session freezes and > is completely unusable. Can you post your logs around when this happens? journalctl should have everything we need. > The reason why I reported this bug is that I think a single application > should not be able to do so, especially not erroneous. Enough said about this.
This issue is gone now and I can't reproduce it any more. I guess there is some other variable I haven't thought about required to reproduce it.
It doesn't ok like it is resolved. Now my Desktop (gnome-shell on wayland) doesn't lock up completely any more but I am getting thousands of these error messages to syslog aside from minor freezes: (gedit:18405): dconf-CRITICAL **: unable to create file '/run/user/[numerical UID]/dconf/user': Permission denied. dconf will not work properly. See also: $ ls -Al /run/user/[numerical UID]/dconf/user -r--------. 1 username1 username1 2 11. Feb 14:12 /run/user/[numerical UID]/dconf/user
(In reply to Christian Stadelmann from comment #12) > It doesn't ok like it is resolved. Now my Desktop (gnome-shell on wayland) > doesn't lock up completely any more but I am getting thousands of these > error messages to syslog aside from minor freezes: > > (gedit:18405): dconf-CRITICAL **: unable to create file > '/run/user/[numerical UID]/dconf/user': Permission denied. dconf will not > work properly. > > See also: > > $ ls -Al /run/user/[numerical UID]/dconf/user > -r--------. 1 username1 username1 2 11. Feb 14:12 /run/user/[numerical > UID]/dconf/user Did you set umask again to 277 ? I suppose this would happen if you set umask like that and then the dconf daemon is spawned from a process that inherited this umask value. But seriously, this isn't really different from doing 'killall gnome-session' and your session going down in flames. In other words, don't do that.