From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30522 invoked by alias); 7 May 2013 06:23:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 30510 invoked by uid 89); 7 May 2013 06:23:14 -0000 X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO autolearn=ham version=3.3.1 Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 06:23:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DCC532ED7E; Tue, 7 May 2013 02:23:11 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9uSCN0JMXxH9; Tue, 7 May 2013 02:23:11 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7AE2F2EAC1; Tue, 7 May 2013 02:23:11 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id F3DA6C2AF9; Tue, 7 May 2013 10:23:05 +0400 (RET) Date: Tue, 07 May 2013 06:23:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH Message-ID: <20130507062305.GH5278@adacore.com> References: <20130501165750.GA453@host2.jankratochvil.net> <87obcoyot3.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87obcoyot3.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-05/txt/msg00174.txt.bz2 > Thanks for doing this. I think it is a nice addition. I agree. My only additional comment, after having hit this assertion, is that it seems a bit harsh to be doing an abort in this case. The problem showed up during a testsuite run, and so I would investigate it regardless. But I can imagine the same issue occurring during a real debugging session trying to chase a bug - I'd be pretty upset to see my session ended like that. Should we consider changing it into an internal_warning? > We could do this for all cleanup-creating functions, at least when using > GCC, if we didn't mind putting a declaration at the start of each such > function: > > #if ... gcc .. > #define CHECK_CLEANUP \ > struct cleanup *__dummy ## __LINE__ \ > __attribute__ ((cleanup (check_cleanup))) \ > = get_checking_cleanup_pointer (); > #endif > > > This would call check_cleanup when the function exited normally, so we > could verify that the cleanup chain was properly reset. That would have helped my investigation, because the error was raised in a frame long after the function causing the problem had returned. Looking at the contents of the cleanup_chain, you get a hint of what it might be, but in my case, it was a null_cleanup, so not so helpful... > I think it would be possible to automate adding this declaration in > all needed spots. I'm curious what you think about it. I'm certainly curious about the suggestion. How would the current code be adapted to make this work? -- Joel