GNOME Bugzilla – Bug 646338
gdk_x_io_error() should call _exit(), not exit()
Last modified: 2014-09-23 19:49:13 UTC
bug 646300 involves a stack trace that looks like: #0 PR_Cleanup() #1 nm_util_deinit() #2 atexit() #3 exit() #4 gdk_x_io_error() #5 [some X call] #6 [deep within the bowels of spidermonkey] #7 [gjs trampoline] #8 [some event handler] The PR_Cleanup() call hangs, because it is trying to free mutexes that are still in use by spidermonkey. Now in this case, it's a bug in nm-util, but it really seems like gdk_x_io_error() ought to be calling _exit() rather than exit(), because losing the X connection is much more like being killed by a signal than it is like being shut down cleanly, and so there shouldn't be any expectation that atexit handlers would run in this case. Amusingly, gdk_x_io_error() says: /* This is basically modelled after the code in XLib. We need * an explicit error handler here, so we can disable our atexit() * which would otherwise cause a nice segfault. though there isn't still any code that would relate to that...
if we're going to change this to be more like a signal, why not change it to raise() instead of _exit() so it actually is a signal? Note, I've had conversations with people before that use atexit() to detect X going away. I don't have a lot of sympathy for users of atexit() but I wouldn't be surprised if this change breaks some apps in weird cases.
(In reply to comment #1) > if we're going to change this to be more like a signal, why not change it to > raise() instead of _exit() so it actually is a signal? That's not really where I was going. I was just saying, atexit() handlers run "at normal program termination", and I think that losing your connection to the X server does not count as "normal".
I've made this change in master now.
*** Bug 737205 has been marked as a duplicate of this bug. ***