GNOME Bugzilla – Bug 600864
metacity calls illegal functions from sigterm handler
Last modified: 2010-03-25 12:22:00 UTC
Just noticed metacity using 99% cpu. I investigated it a bit with mccann and it's because metacity is calling meta_finalize from a sigterm handler. This is a big no-no. There is a set of maybe 10 - 15 functions that are legal to call from a sigterm handler.
Created attachment 147031 [details] bt
Created attachment 147034 [details] [review] Don't call meta_finalize from SIGTERM handler It's not a legal function to call from a signal handler. Instead defer until going back to the main loop.
downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=533239
Created attachment 147047 [details] [review] Another take The previous patch doesn't work. We never get a hangup on the fd when the pipe is closed. This means we're leaking the fd across a fork() call somewhere in the code. Rather than tracking that down, I've changed the patch slightly to not rely on a hangup but instead watch for an explicit write call.
Note that metacity is also doing something bogus with its SIGCHLD handler. You can't call g_signal_emit in that context either.
Adding Michael because he alluded to these issues in his blog.
Thanks Ray; patch looks nice - of course, the lazy man in me would use a g_idle_add - and get screwed over later when the signal was caught in the critical section of a mutex ;-) cf. mono's erstwhile problems in that regard. Patch looks lovely & thanks for the CC :-)
See bug 596200 for a patch fixing similar problems with SIGCHLD (patch there needs a little adaptation for Metacity, there's one explicit reference to mutter in a string in the code.)
Comment on attachment 147047 [details] [review] Another take this is in master now.
Created attachment 149856 [details] [review] metacity-race-autologin-cleanup.patch Attached patch is not gcc-4.4.1 -Werror compatible (warning about unused result). Attached simple patch fixes this problem.