From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23401 invoked by alias); 29 Jun 2007 01:36:44 -0000 Received: (qmail 23333 invoked by uid 22791); 29 Jun 2007 01:36:44 -0000 X-Spam-Check-By: sourceware.org Received: from b.mail.sonic.net (HELO b.mail.sonic.net) (64.142.19.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Jun 2007 01:36:42 +0000 Received: from webmail.sonic.net (b.webmail.sonic.net [64.142.100.148]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l5T1acmk007270; Thu, 28 Jun 2007 18:36:38 -0700 Received: from 12.7.175.2 (SquirrelMail authenticated user msnyder) by webmail.sonic.net with HTTP; Thu, 28 Jun 2007 18:36:38 -0700 (PDT) Message-ID: <11470.12.7.175.2.1183080998.squirrel@webmail.sonic.net> In-Reply-To: <20070628231153.GA14231@caradoc.them.org> References: <9270.12.7.175.2.1183069663.squirrel@webmail.sonic.net> <20070628224815.GC12578@caradoc.them.org> <655C3D4066B7954481633935A40BB36F041427@ussunex02.svl.access-company.com> <20070628231153.GA14231@caradoc.them.org> Date: Fri, 29 Jun 2007 02:05:00 -0000 Subject: Re: [OB] Add cleanup, source.c From: msnyder@sonic.net To: "Michael Snyder" , msnyder@sonic.net, gdb-patches@sourceware.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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-06/txt/msg00516.txt.bz2 > On Thu, Jun 28, 2007 at 03:59:23PM -0700, Michael Snyder wrote: >> >> >> > There's no call to do_cleanups in this function, so it's quite hard to >> > see if this cleanup will be run or discarded if error is not called. >> >> When are they ever discarded? >> >> My last understanding of the mechanism was that the cleanups >> always get called, eventually. Presumably when we return to >> the command / event loop. > > No, that's not right. Cleanups are often discarded after a successful > operation, in order to not free something that would have been cleaned > up on error. Well, I'm pretty sure you're mistaken. Or put it another way -- one of us is mistaken, and naturally, I think it's you. ;-) 1) From logic: I know that frequently when we allocate something, we call a make_cleanup function to register it to be freed -- and then we never actually free it. We depend on it being freed at cleanup time. Which is exactly what we're doing here. 2) Empirically: I run gdb with this change, and set a breakpoint at do_freeargv. It gets called, from command_handler (event-top.c). So the change accomplishes what it is meant to do. 3) By example: in the same module (source.c), three other functions call buildargv and make_cleanup_freeargv -- and none of them calls do_cleanups. So you're holding me to a higher standard than the preexisting code. ;-)