From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23940 invoked by alias); 26 Nov 2012 16:54:16 -0000 Received: (qmail 23929 invoked by uid 22791); 26 Nov 2012 16:54:14 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_XZ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 16:53:57 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAQGroga000563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2012 11:53:50 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAQGrm1f022900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 26 Nov 2012 11:53:48 -0500 From: Tom Tromey To: "Pierre Muller" Cc: "'Joel Brobecker'" , "'Pedro Alves'" , "'Eli Zaretskii'" , Subject: Re: [RFC-v4] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior) References: <834nm07z0s.fsf@gnu.org> <5077FEB9.4030304@redhat.com> <83y5jb7rfe.fsf@gnu.org> <006001cdaada$00c81f00$02585d00$@muller@ics-cnrs.unistra.fr> <20121024194517.GK3555@adacore.com> <011901cdb2ab$48076b90$d81642b0$@muller@ics-cnrs.unistra.fr> <20121105171121.GA2972@adacore.com> <50991f5f.8382440a.1100.ffff82abSMTPIN_ADDED@mx.google.com> <509ABA17.30507@redhat.com> <000301cdbd96$f5cd9f10$e168dd30$@muller@ics-cnrs.unistra.fr> <20121122173019.GF9964@adacore.com> <15690.5992342674$1353883881@news.gmane.org> Date: Mon, 26 Nov 2012 16:54:00 -0000 In-Reply-To: <15690.5992342674$1353883881@news.gmane.org> (Pierre Muller's message of "Sun, 25 Nov 2012 23:50:07 +0100") Message-ID: <87624si9ur.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-11/txt/msg00672.txt.bz2 >>>>> "Pierre" == Pierre Muller writes: Joel> Are we missing a cleanup/xfree? Pierre> I added some, please check that part, as I have Pierre> no experience at all with using make_cleanup Pierre> related functions... Pierre> In particular, I didn't really get if it is OK to call Pierre> do_cleanups with a possibly NULL argument... The simplest way to approach cleanups, which I recommend in nearly all cases, is to treat them as block-scoped and to always pass the result of a make_cleanup call to do_cleanups. Try to avoid tricks with conditions and possibly-NULL cleanup pointers, this usually leads to trouble. Pierre> + struct cleanup *section_cleanup = 0; I think there's no need to initialize this, since you re-set it later. Pierre> + section_data = xzalloc (PE_SECTION_TABLE_SIZE Pierre> + * sizeof (struct read_pe_section_data)); Pierre> + Pierre> + section_cleanup = make_cleanup (xfree, section_data); Ok so far, but... Pierre> + section_data = xrealloc (section_data, otherix Pierre> + * sizeof (struct read_pe_section_data)); ... this can free the original pointer. What you want is: section_cleanup = make_cleanup (free_current_contents, §ion_data); This will free the current value of the pointer, instead of capturing the value when the cleanup is made. Pierre> /* Discard expdata. */ Pierre> do_cleanups (back_to); Pierre> + /* Discard section_data. */ Pierre> + do_cleanups (section_cleanup); Cleanups are a stack, so you can just invoke do_cleanups on the outermost one. Just delete the local variable 'back_to'. Tom