From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23955 invoked by alias); 4 Jul 2007 17:35:46 -0000 Received: (qmail 23941 invoked by uid 22791); 4 Jul 2007 17:35:45 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jul 2007 17:35:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 43DA42A9BDB; Wed, 4 Jul 2007 13:35:41 -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 ysMxFfkJYqBe; Wed, 4 Jul 2007 13:35:41 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 0A9042A9BD1; Wed, 4 Jul 2007 13:35:41 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7A68EE7B54; Wed, 4 Jul 2007 10:37:57 -0700 (PDT) Date: Wed, 04 Jul 2007 17:35:00 -0000 From: Joel Brobecker To: Jim Blandy Cc: Eli Zaretskii , Michael Snyder , drow@false.org, Michael.Snyder@access-company.com, gdb-patches@sourceware.org Subject: Re: [OB] Add cleanup, source.c Message-ID: <20070704173757.GD6035@adacore.com> References: <20070628224815.GC12578@caradoc.them.org> <655C3D4066B7954481633935A40BB36F041427@ussunex02.svl.access-company.com> <20070628231153.GA14231@caradoc.them.org> <11470.12.7.175.2.1183080998.squirrel@webmail.sonic.net> <20070629113407.GA13561@caradoc.them.org> <003201c7ba8c$d6e0e840$677ba8c0@sonic.net> <000b01c7bb2f$d88684e0$677ba8c0@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2007-07/txt/msg00093.txt.bz2 > What's going on here is that GDB uses one construct, cleanups, to > implement two different useful behaviors, and does so in a perilous > way. > where 'cleanup_success' discards failure handlers and runs finally > handlers. The 'error' function would call a companion to that named > 'cleanup_on_failure', which runs both finally and failure handlers. A very interesting analysis, Jim. I confess that up to today, I have been using the two concepts interchangeably, so I'm pretty sure that I have introduced the potential for memory leaks :-(. > So. Only 270 calls to 'do_cleanups' and 47 calls to > 'discard_cleanups' to examine. Good luck. Let me know if you'd like some help, I feel partly responsible for the mess. We can split the number of files that need to be inspected. -- Joel