From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17123 invoked by alias); 1 May 2013 15:21:25 -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 17114 invoked by uid 89); 1 May 2013 15:21:24 -0000 X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,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 15:21:22 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r41FLKTu030364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 May 2013 11:21:21 -0400 Received: from host2.jankratochvil.net (ovpn-116-69.ams2.redhat.com [10.36.116.69]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r41FLGqH003049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 May 2013 11:21:19 -0400 Date: Wed, 01 May 2013 15:21:00 -0000 From: Jan Kratochvil To: Phil Muldoon Cc: gdb@sourceware.org Subject: Re: Cleanups and Exception handlers Message-ID: <20130501152116.GA7529@host2.jankratochvil.net> References: <5180EE37.3020507@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5180EE37.3020507@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-05/txt/msg00007.txt.bz2 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. > 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: > Example 2: > > > TRY_CATCH (except, RETURN_MASK_ALL) > { > struct cleanups cleanups = > make_cleanup_ui_out_tuple_begin_end (out, NULL); > ... > // Do some other stuff > do_cleanups (cleanups); > } > if (except.reason < 0) > { > // Some exception handling code > } > > 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 ()); This will execute all pending cleanup handlers inside the TRY_CATCH block. But no cleanups outside of the TRY_CATCH block. > Question 3) > > For cleanups created and registered exclusively in the TRY_CATCH > block, on some exception being raised are they cleaned up > automatically? Yes, see above: 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 ()); > 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. Jan