TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!
Greetings, Today I Learned :) if a thread throws an exception that isn't rescued by the top of the thread, it'll crash the app's main thread with 'Program received signal: “SIGABRT”.' That's been plaguing me since I started doing MacRuby development; every time I tried to start up multiple threads, the app became incredibly fragile and, unlike the main thread, it wouldn't show ruby traces. Now I just wrap threads in begin/rescue blocks, and I'm all good. Good programming practice anyway, but the failure mode is unobvious if you don't. Hopefully this helps someone else! -- Morgan
If you find this exception-shifting behavior troubling, please open a ticket. Could you explain why introducing the begin/rescue pair that is good programming practice? Matt On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote:
Greetings, Today I Learned :) if a thread throws an exception that isn't rescued by the top of the thread, it'll crash the app's main thread with 'Program received signal: “SIGABRT”.'
That's been plaguing me since I started doing MacRuby development; every time I tried to start up multiple threads, the app became incredibly fragile and, unlike the main thread, it wouldn't show ruby traces.
Now I just wrap threads in begin/rescue blocks, and I'm all good. Good programming practice anyway, but the failure mode is unobvious if you don't.
Hopefully this helps someone else!
-- Morgan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Greetings, On Mon, Mar 14, 2011 at 6:57 AM, Matt Massicotte <massicotte@apple.com>wrote:
If you find this exception-shifting behavior troubling, please open a ticket.
What bugs me about the behavior in this case is that if the exact same operation is done on the main thread, it throws a very nice, normal Ruby exception trace, and I know immediately what boneheaded move I made. :) If it happens on an NSThread, it gives an absolutely opaque 'SIGABRT' on the main thread. I'll see if I can create a simple example that demonstrates it. Could you explain why introducing the begin/rescue pair that is good
programming practice?
Historically I've found that when I have a consumer thread that does 'work', I don't want an unanticipated failure of any one work unit to prevent future work units from being processed. So at the top level of any thread action (in this case, in the method triggered on NSTimer firing) I wrap the work-processing code in a rescue block, so if an unexpected failure happens, I log it, and move on to the next work unit. In some (most?) systems an uncaught exception will kill off the thread, and apparently something similar is true in MacRuby. Matt
Hope that helps. -- Morgan Schweers On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote:
Greetings, Today I Learned :) if a thread throws an exception that isn't rescued by the top of the thread, it'll crash the app's main thread with 'Program received signal: “SIGABRT”.'
That's been plaguing me since I started doing MacRuby development; every time I tried to start up multiple threads, the app became incredibly fragile and, unlike the main thread, it wouldn't show ruby traces.
Now I just wrap threads in begin/rescue blocks, and I'm all good. Good programming practice anyway, but the failure mode is unobvious if you don't.
Hopefully this helps someone else!
-- Morgan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Mar 14, 2011, at 10:35 AM, Morgan Schweers wrote:
Greetings,
On Mon, Mar 14, 2011 at 6:57 AM, Matt Massicotte <massicotte@apple.com> wrote: If you find this exception-shifting behavior troubling, please open a ticket.
What bugs me about the behavior in this case is that if the exact same operation is done on the main thread, it throws a very nice, normal Ruby exception trace, and I know immediately what boneheaded move I made. :) If it happens on an NSThread, it gives an absolutely opaque 'SIGABRT' on the main thread.
I'll see if I can create a simple example that demonstrates it.
That would be great. This behavior is not macruby-specific, but bites anyone that sees exceptions on non-main threads.
Could you explain why introducing the begin/rescue pair that is good programming practice?
Historically I've found that when I have a consumer thread that does 'work', I don't want an unanticipated failure of any one work unit to prevent future work units from being processed. So at the top level of any thread action (in this case, in the method triggered on NSTimer firing) I wrap the work-processing code in a rescue block, so if an unexpected failure happens, I log it, and move on to the next work unit. In some (most?) systems an uncaught exception will kill off the thread, and apparently something similar is true in MacRuby.
Ah. Yes, in the special-case of executing work that has zero side-effects on the rest of your system, this can be helpful.
Matt
Hope that helps.
-- Morgan Schweers
On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote:
Greetings, Today I Learned :) if a thread throws an exception that isn't rescued by the top of the thread, it'll crash the app's main thread with 'Program received signal: “SIGABRT”.'
That's been plaguing me since I started doing MacRuby development; every time I tried to start up multiple threads, the app became incredibly fragile and, unlike the main thread, it wouldn't show ruby traces.
Now I just wrap threads in begin/rescue blocks, and I'm all good. Good programming practice anyway, but the failure mode is unobvious if you don't.
Hopefully this helps someone else!
-- Morgan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Morgan, Well in theory, you should NOT get a segfault when doing that. When an exception isn't rescued inside a Thread, the correct behavior is that the thread will quit, and that the exception will be silently ignored. Then, once the Thread object is garbage collected, if the exception has not been retrieved from the Thread object (for instance, if #join has never been called on it), then a warning message is printed on stderr with the exception backtrace, for debugging purposes. It would be nice if you could reproduce the segfault in a small test case, because it looks bad (we should never segfault) :) Laurent On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote:
Greetings, Today I Learned :) if a thread throws an exception that isn't rescued by the top of the thread, it'll crash the app's main thread with 'Program received signal: “SIGABRT”.'
That's been plaguing me since I started doing MacRuby development; every time I tried to start up multiple threads, the app became incredibly fragile and, unlike the main thread, it wouldn't show ruby traces.
Now I just wrap threads in begin/rescue blocks, and I'm all good. Good programming practice anyway, but the failure mode is unobvious if you don't.
Hopefully this helps someone else!
-- Morgan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (3)
-
Laurent Sansonetti
-
Matt Massicotte
-
Morgan Schweers