discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux


From: David Chisnall
Subject: Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux
Date: Thu, 7 Dec 2017 08:34:23 +0000

On 6 Dec 2017, at 19:04, Lobron, David <address@hidden> wrote:
> 
> So the question is: why is abort being called here?  Why doesn't the stack 
> continue to unwind?  I did notice that certain frames seem to be skipped in 
> the unwind sequence above, and the line numbers reported do change a little - 
> could that be related to the problem?  I'm linking with libunwind-1.1, and 
> I'm building it with a fairly standard set of options (copied below). 

When you throw an exception, first the runtime sets up some ObjC-specific 
things and then calls into the unwind library.  The unwind library then walks 
up the stack, calling back into the runtime (or another language’s) personality 
function for each frame to indicate whether it’s found a handler or not.

For each frame, the personality function says one of three things: this one 
isn’t important, this one contains cleanups, and this one contains a matching 
catch handler.

If no personality function call finds a catch handler, then the unwinder 
returns to the runtime, which then calls abort.  That doesn’t seem to be 
happening here.

If there is a catch handler, then the unwinder walks the stack again, only this 
time when it finds a catch block the personality function sets two registers 
(the exception object and the index of the cleanup in a table) and the unwind 
library returns control to the program.

Once the program has run the cleanup code, it will call _Unwind_Resume and will 
continue unwinding.  If the unwinder then doesn’t find another cleanup or catch 
on the stack, then it will call abort, because _Unwind_Resume isn’t expected to 
return, but it now doesn’t have anywhere to unwind to.

TL;DR: It looks as if the unwinder is first finding a catch block when the 
exception is thrown, but then not finding it when the exception is rethrown 
after running cleanups.  This is quite surprising, and the only thing I can 
think of that would cause it (modulo bugs in the ObjC personality function - 
which are entirely possible as it’s a horribly complex piece of code) is if the 
exception passed back into _Unwind_Resume is not the same exception as the one 
initially thrown.

Please can you also try sticking a breakpoint on objc_exception_throw and 
objc_exception_rethrow?  There are also a bunch of debug logs that are compiled 
out in the EH code - if you #define DEBUG_LOG at the top of eh_personality.c 
then you should see them and get a better idea of what’s going on.

David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]