From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26083 invoked by alias); 1 May 2013 18:46:14 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 26074 invoked by uid 89); 1 May 2013 18:46:14 -0000 X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 01 May 2013 18:46:13 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r41IkC0F029973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 May 2013 14:46:12 -0400 Received: from localhost.localdomain (ovpn-116-98.ams2.redhat.com [10.36.116.98]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r41IkA39016105; Wed, 1 May 2013 14:46:11 -0400 Message-ID: <518162F2.1000704@redhat.com> Date: Wed, 01 May 2013 18:46:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Jan Kratochvil CC: gdb@sourceware.org Subject: Re: Cleanups and Exception handlers References: <5180EE37.3020507@redhat.com> <20130501152116.GA7529@host2.jankratochvil.net> In-Reply-To: <20130501152116.GA7529@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00008.txt.bz2 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