discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Problem with catching exceptions on ARM


From: Mathias Bauer
Subject: Re: Problem with catching exceptions on ARM
Date: Fri, 21 Feb 2014 16:14:56 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0



Am 21.02.14 11:37, schrieb 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?

I see calls to objc_exception_throw, objc_begin_catch and objc_end_catch in both cases and finally the program execution continues at the line of code behind the last catch block.

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)?

I'm not sure if I got your question, sorry.

Assuming I have the function call sequence 1 -> 2 -> 3, and in "3" an exception is thrown that is caught in "1". This is the scenario that works fine, as I reported. Now I add a "cleanup" variable in 2. Is that what you wanted me to do? Then I can report that in this case the program also doesn't continue, the catch block is never reached.

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.

Yes, you are right. But the result is the same in my tests, rethrow in the catch block or throwing a new exception inside or outside of the catch block gives the same result (endless calls to internal_objc_personality).

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?

Yes, as described above: the exception shall be caught in a function above on the stack, but this catch block is never hit.

I saw in the version of eh_personality.c that I have in libobjc2, the cleanup function is commented out, so it does nothing.

I checked it out from

http://svn.gna.org/svn/gnustep/libs/libobjc2/trunk

Regards,
Mathias



reply via email to

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