Re: Problem with catching exceptions on ARM

[David Chisnall]

On 21 Feb 2014, at 10:06, Mathias Bauer <mathias_bauer@gmx.net> wrote:

> Am 20.02.14 18:27, schrieb Mathias Bauer:
> 
>> I tested, that a simple @try/@catch works (an exception thrown in a
>> function called from the @try block is caught successfully and the
>> program exits normally). But throwing another exception in the function
>> that caught the exception freezes the program again. It doesn't matter
>> if the second exception is thrown inside the @catch block or outside of it.

Thanks for your effort in working on this.

> More exactly:
> 
> EH works if an exception is thrown and caught in a function and then another 
> exception is thrown and caught in that same function.

So, in both cases the exception is thrown and caught in the same function?  The 
unwinder is still unwinding through the objc_exception_throw() function, but 
it's caught in the function that calls that?

> EH works if an exception is thrown in a function and caught in another 
> function above on the call stack.

So it is managing to unwind through multiple frames that don't do anything with 
it.  Have you checked what happens if one of these contains an @finally block, 
but no @catch?  Or, probably better, an __attribute__((cleanup)) variable (so 
it's definitely a cleanup and not a catchall)?

> The program does not continue if an exception is thrown and caught in a 
> function and then another exception is thrown in that same function and shall 
> be caught in a function above on the call stack (the typical "rethrow" 
> scenario).

Hmm, this isn't quite the rethrow scenario, if it's a different exception 
that's being thrown.  They should be two different paths in the runtime.  In 
the pure rethrow case, the same exception structure is used and it is marked as 
a rethrow so the generic unwinder may reuse some cached data (I don't think it 
does, but it's allowed to).

In the throwing-a-different-exception case, we should first be doing the 
cleanup for the old exception and then throwing a new one.  It may be that 
we're not doing the cleanup and so think that we're rethrowing an exception 
when actually we're throwing a new one, which would probably account for the 
behaviour that you see.

> From debugging the code I could see that in this case the function 
> "internal_objc_personality" in eh_personality.c only finds a handler that is 
> a cleanup, and so the function is called again and again, always with the 
> same result.

Is there a catch somewhere higher up?  

David





-- Sent from my Apple II