From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65992 invoked by alias); 16 May 2015 00:03:49 -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 65980 invoked by uid 89); 16 May 2015 00:03:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 16 May 2015 00:03:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 00C1628A5A; Fri, 15 May 2015 20:03:46 -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 nPmiU0ahVKO3; Fri, 15 May 2015 20:03:45 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B3838289D7; Fri, 15 May 2015 20:03:45 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6B50840DAA; Fri, 15 May 2015 17:03:49 -0700 (PDT) Date: Sat, 16 May 2015 00:03:00 -0000 From: Joel Brobecker To: Doug Evans Cc: Pedro Alves , gdb-patches , Jerome Guitton Subject: Re: [RFA/commit] Memory leak in on reading frame register Message-ID: <20150516000349.GM4767@adacore.com> References: <1431100524-7793-1-git-send-email-brobecker@adacore.com> <55508A83.3060605@redhat.com> <20150511205312.GE4767@adacore.com> <5551CB20.4090104@redhat.com> <20150515155823.GL4767@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg00422.txt.bz2 > > gdb/ChangeLog: > > > > * infrun.c (handle_inferior_event_1): Renames handle_inferior_event. > > (handle_inferior_event): New function. > > > > Tested on x86_64-linux. No regression. > > Not that this has to be changed here, but I'm wondering why all value > mark/frees aren't done via cleanups. I can imagine sometimes it's not, > technically, necessary, and I can imagine there's some history/inertia > here, but having two ways to do this (using a cleanup or not) leaves > the reader having to wonder if using a cleanup was errantly skipped. I guess it depends on whether you think you need the certainty of the cleanup or not. I think both approaches are valid depending on the context. In this case, I asked myself that question, and I didn't see a real need for it, since my thinking was that, if an exception occurs and propagates through handle_inferior_event, then chances are it'll propagate all the way, which would then lead to values being cleaned up as well. So I went with the current pattern. But I can change it to a cleanup if people prefer. I don't mind. -- Joel