[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 <dlobron@akamai.com> 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
- Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/05
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/06
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/06
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/06
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/06
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux,
David Chisnall <=
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/11
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/11
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/11
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/11
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/11
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/12