GNOME Bugzilla – Bug 667423
unresponsive application behavior
Last modified: 2021-07-05 14:44:54 UTC
Created attachment 204759 [details] screenshot Currently we show a dialog (like the one attached) when a window/application is not responding. It isn't super. * We don't seem to detect unresponsive windows until the user tries to click close or similar * The visual appearance of the window doesn't indicate it isn't responding * The dialog doesn't feel connected to the window - or part of the OS chrome * We make no attempt to apologize for the bustedness or get the user back to where they were * The dialog isn't very slick * If the user elects to kill the app there is no record of the problem * There is no way to report the problem - hangs are just as bad as crashes So there are a couple things here. 1. Need a new design for how unresponsive windows/apps appear in the shell (both foreground and background) 2. We should kill the app in a way that allows: a. the problem to be accurately described to the user b. reported as a problem to be analyzed and fixed One note about 2. is that using SIGABRT would allow us to get a good problem report for (b) but would result in a misleading description for (a). Wonder if we could have a different signal for not-responding.
2 cases to keep in mind: - apps interrupted via Ctrl-Z - apps interrupted by a debugger (potentially a debugger running on another computer) Those 2 are not really unresponsive apps. Or rather, they are unresponsive by user choice. In particular in the debugger case, the user usually doesn't want the WM trying to "tamper" with the app. I'd be very unhappy if I was stepping through some complex part of GtkTreeView code and the app I was debugging suddenly received a SIGABRT. I think it's fine if you change the visual representation of the window (turning it monochrome, overlaying a frowny face dialog or whatever), because that's essentially what happened before we had compositing. But doing more invasive things to the window might be tricky, dunno.
Just a few comments: The right signal is probably not ABRT but QUIT (which results in a core dump, but cannot be confused with a "natural" assertion failure). The problem is, the app could have an handler for that or have it ignored / blocked (this holds for both ABRT and QUIT), so mutter currently goes with KILL immediately. When compiled for linux, mutter could check /proc/<pid>/wchan, and not show any dialog if the wait channel is "ptrace_stop" (debugger) or "do_signal_stop" (ctrl-z). This assuming that the main thread is also the GUI thread (which is usually true for gtk apps). The implementation of this feature is currently completely self-contained within mutter, and comes originally from metacity. Changing it to be a shell dialog would require additional hooks in MetaPlugin or the like.
But checking /proc/<pid>/wchan is racy, because it assumes that I'm not debugging the app right when you check it. Because if I just pressed "continue" in gdb, you'll nuke it. This will probably be hard to trigger, but still lead to spurious application crashes in people's debuggers...
Well, it's not that you kill the app immediately if you don't see the right wchan. Rather, I was thinking to use it so to avoid overlaying the window with the gray shade (which is useful, if you're debugging theme problems...) or showing the "Force quit" dialog. Obviously, nothing is killed if the user says cancel, and quit is always emitted if the user says quit.
What you want to check is whether a process is being ptrace attached to, not whether it is actually being stopped due to ptrace. The wchan check will look for a process that is actually stopped, hence not useful. A simple way to detect whether a process is being ptrace attached to is to simply trying to attach to it. Since only one debugger process can be ptraced attached to a specific process this should immediately fail if a process is run in gdb. I think this isn't as ugly as one might think at first, given that the attach would only be attempted if the process is actually frozen.
(In reply to comment #5) > What you want to check is whether a process is being ptrace attached to, not > whether it is actually being stopped due to ptrace. The wchan check will look > for a process that is actually stopped, hence not useful. A simple way to > detect whether a process is being ptrace attached to is to simply trying to > attach to it. Since only one debugger process can be ptraced attached to a > specific process this should immediately fail if a process is run in gdb. I > think this isn't as ugly as one might think at first, given that the attach > would only be attempted if the process is actually frozen. /proc/<pid>/status has a field "TracerPid".
*** Bug 618493 has been marked as a duplicate of this bug. ***
I think that the dialogs themselves have been improved recently, but I'm assuming that the rest of the issues are still valid.
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.