Re: Cleanups and Exception handlers

On 01/05/13 16:21, Jan Kratochvil wrote:
> On Wed, 01 May 2013 12:28:07 +0200, Phil Muldoon wrote:
>> Question 1)
>>
>> What is the rule regarding cleanup chains that were created outside of
>> an exception handler, but where
> 
>> additional cleanups were registered
>> and not processed (cleanedup) inside the exception handler.
> 
> When you end TRY_CATCH block (therefore not exiting the block by a thrown
> exception) there must be no leftover cleanups.  You must do_cleanups or
> discard_cleanups them all.  Debugging some new gdb_assert at that point here,
> it may make sense there.

Ok thanks.  That rules out a pattern with (the tuple example) for
Python.  As that cleanup lives as long as the tuple needs to be open
(which tends to be function length).

>> Question 2)
>>
>> If in the above example, something goes wrong, does one have to call
>> do_cleanups() in the exception handling block (IE if (except.reason <
>> 0))
> 
> You have to call do_cleanups in the same TRY_CATCH block.  TRY_CATCH
> completely separates handling of exceptions outside of the block vs. inside of
> the block.
> 
> Therefore "Example 2" is right:

In the first example, where did the previously registered cleanup
outside of the TRY_CATCH go? Was it discarded (or leaked?)


>> In this example we create a pointer to the cleanup chain, and perform
>> a tuple cleanup.  If I call do_cleanups() in this example (assuming
>> nothing went wrong in the TRY_CATCH block), the tuple is cleaned up
>> properly.  But what happens if something happens and the exception
>> handling "if" is called.
> 
> In such case cleanups are executed already inside the TRY_CATCH block at the
> time the exception was thrown.  throw_exception contains:
> 	do_cleanups (all_cleanups ());

Ok thanks, so in the case of cleanups entirely encapsulated in the
TRY_CATCH block there is no need to do anything in the later exception
handling block (the "if", after).

>> This all came about as MI tuples tend to be "long lived" cleanups and
>> in Python we have to handle every potential GDB exception call in an
>> exception handler to prevent propagation upwards.
> 
> It seemed to me that there were too many TRY_CATCH blocks even in cases where
> nothing can throw an exception.

This is because most (though I have no audited all of them) calls to
ui_out_* use *_filtered function calls (at least when the output is
directed to the CLI).  These can be interrupted from GDB and Python
has to handle the resulting GDB generated keyboard interruption
exception.  It's a massive pain in the neck. ;)

Cheers

Phil