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: Tue, 12 Dec 2017 15:54:08 +0000

On 12 Dec 2017, at 15:30, Lobron, David <dlobron@akamai.com> wrote:
> 
> I tweaked my code a bit.  I now have an ObjC class in a .m file that throws 
> an exception like this:
> 
> - (void)poke
> {
>  [NSException raise:@"Exception" format:@"Exception"];
> }

This doesn’t add anything, because the exception is thrown from the NSException 
-raise method, which is ObjC and will do a @throw from an ObjC compilation unit 
inside -base.  For a libobjc2 test, I’ll need it to not depend on -base at all 
when I add it to the test suite.

> I call this from a .m file, inside an NS_HANDLER, and then re-raise the 
> exception.  The goal here is to pass the NSException through a plain ObjC 
> frame:
> 
> - (void)poke
> {
>    NS_DURING
>      [_oc poke];
>    NS_HANDLER
>      NSLog(@"Caught second exception");
>      [localException raise];
>    NS_ENDHANDLER
> }


This is easier to read if you don’t use the macros.  Now you’re doing 
@catch(id), which is catching the exception.  You’re then throwing it again 
(@throw inside the -raise method), rather that rethrowing it (@throw with no 
argument).  This wants to be an @finally though, because we’re looking for a 
case where the search phase and the unwinding phase do different things.

> 
> Finally, I call this from a .mm file, inside a C++ class method:
> 
> void tryCpp() {
>    Tester *t = [[Tester new] autorelease];
>    try {
>      try {
>        NSLog(@"tryCpp starting");
>        [t poke];
>      } catch(NSException *e) {
>        NSLog(@"tryCpp aught ObjC exception");
>        throw e;
>      }
>    } catch(...) {
>      NSLog(@"tryCpp caught outer exception");
>    }
>  }
> 
> 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.

David




reply via email to

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