GNOME Bugzilla – Bug 596200
Freeze using GNOME Shell
Last modified: 2009-11-30 01:42:03 UTC
I've been experiencing a freeze for some time when using GNOME Shell on the long run. No precise causes come to my mind. It may have been present since the beginning of the Shell, since I'm able to isolate this bug only because the Shell has become quite stable otherwise in recent weeks. I think that's Mutter fault because in those cases, 'killall mutter' does not work, only using '-9' does. Then everything is working fine. The attached trace is before trying to kill mutter.
Created attachment 143919 [details] gdb trace of the freeze
(In reply to comment #0) > I think that's Mutter fault because in those cases, 'killall mutter' does not > work, only using '-9' does. Not relevant; gnome-shell is a module loaded into mutter; it can lock up the process just as easily as the mutter-specific code can. But in fact, in this case it *is* a mutter bug, inherited from metacity; it's doing way too much in src/core/main.c:sigchld_handler, and in particular in your case, it ends up trying to lock a mutex that it already had locked outside the handler.
(In reply to comment #2) > Not relevant; gnome-shell is a module loaded into mutter; it can lock up the > process just as easily as the mutter-specific code can. Yeah, I meant (Mutter+Shell), as opposed to being an X freeze or something. > But in fact, in this case it *is* a mutter bug, inherited from metacity; it's > doing way too much in src/core/main.c:sigchld_handler, and in particular in > your case, it ends up trying to lock a mutex that it already had locked outside > the handler. So that would explain why base SIGTERM does not work. Though, as I said above, the attached trace is done *before* I sent the signal, since I had found those handlers in my first traces and I wanted to track the original bug.
Created attachment 148142 [details] [review] Fix handling of SIGCHLD The commit that removed metacity-dialog added a global SIGCHLD handler that caused problems by (a) calling waitpid(-1) and thus breaking g_child_watch for everyone else, and (b) doing too much from a signal handler and sometimes causing deadlocks (bug 596200). This removes the global handler and has each zenity user create its own child watch to watch for exit. (It also fixes the window class of the zenity dialogs, so that meta_window_present_delete_dialog() will work again.)
Review of attachment 148142 [details] [review]: Looks great to me. (See bug 600864 for the SIGTERM side of the story, one several outstanding Metacity patches that needs to get committed to both Metacity and Mutter.)
Comment on attachment 148142 [details] [review] Fix handling of SIGCHLD Attachment 148142 [details] pushed as 988d2ff - Fix handling of SIGCHLD
Reassigning to metacity; the patch here won't apply cleanly, but it's mostly just a matter of s/mutter/metacity/ (or /meta/). (The bug also doesn't affect metacity as much as it does mutter, since metacity doesn't do as much launching stuff as gnome-shell does, but it's definitely still possible for metacity to deadlock when the force quit zenity dialog exits, because of the current SIGCHLD handler.)
fixed in metacity master.
Looks like there are some leftovers in include/util.h, removing those fixes the build for me. /** * An object which exists purely to attach signals to; this is to receive * signals when a child process exits. The signal is "sigchld" with no detail. */ extern MetaNexus *sigchld_nexus;
Thanks, http://git.gnome.org/cgit/metacity/commit/?id=19d85c85667941fec25a65516d84bd7a5c0bb22b