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: Mon, 18 Dec 2017 20:19:49 +0000

> On 18 Dec 2017, at 20:04, Lobron, David <address@hidden> wrote:
> 
> Hi David-
> 
>>> The goal here is to do what you suggested above, namely, force the ObjC 
>>> runtime to turn the NSException into a C++ exception for delivery to the 
>>> tryCpp method, which is a plain C++ instance method.  But the debug output 
>>> (copied below) suggests that is not happening: all of the exception 
>>> personalities are of class GNUCOBJC.  Am I missing a step here, or not 
>>> understanding the way exception personalities are passed through frames?  
>>> I'm still learning this, so maybe I'm missing something obvious.
>> 
>> Try to recreate the structure of your original failure with the same mix of 
>> ObjC/C++/ObjC++ stack frames and the same cleanups / catches.
> 
> I've got a working unit test in the libobjc2 Test directory, which depends 
> only on libobjc2.

That’s great.  When you have it in a failing form, please can you send me a 
pull request containing the test?

>  I'm trying to reproduce my original failure by doing the following:
> 
> 1. Throw an exception from a .mm file.
> 
> 2. Pass it through a .m file.
> 
> 3. Catch the exception in a C++ class in another .mm file.
> 
> I tried a few versions of this, including catching the exception inside a C++ 
> class, but so far I have not been able to induce the runtime to coerce a 
> GNUCOBJC exception into a GNUCC++ one.  The debug logs report:
> 
> New personality function called 0xd28300
> Class: GNUCOBJC
> LSDA: 0x4024ec
> Search phase...
> handler: 1
> New personality function called 0xd28300
> Class: GNUCOBJC
> LSDA: 0x4024ec
> Phase 2: Fight!
> Not the handler frame, looking up the cleanup again
> Caught exception in C++

These might be slightly misleading, because you only get these debug messages 
from ObjC stack frames, not from C++ or ObjC++.  It might help you to add some 
DEBUG_LOG statements to __gnustep_objcxx_personality_v0.

Looking at the code, it appears that the exception is coerced to a C++ 
exception if it is thrown from an ObjC stack frame.  Everything else looks as 
if it ought to be able to handle either kind of exception though, so I’m still 
somewhat confused as to the cause of this one.

David




reply via email to

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