From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88300 invoked by alias); 6 Feb 2019 04:08:33 -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 88288 invoked by uid 89); 6 Feb 2019 04:08:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=loss, 1083 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Feb 2019 04:08:32 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x1648Pqh023774 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 5 Feb 2019 23:08:30 -0500 Received: by simark.ca (Postfix, from userid 112) id 7A9F01E882; Tue, 5 Feb 2019 23:08:25 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id ADF621E4B5; Tue, 5 Feb 2019 23:08:23 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 06 Feb 2019 04:08:00 -0000 From: Simon Marchi To: Philippe Waroquiers Cc: gdb-patches@sourceware.org Subject: Re: [RFAv3 1/2] Fix leak of identifier in macro definition. In-Reply-To: <20190126223117.6718-2-philippe.waroquiers@skynet.be> References: <20190126223117.6718-1-philippe.waroquiers@skynet.be> <20190126223117.6718-2-philippe.waroquiers@skynet.be> Message-ID: <088b04db86e32fc4c25dc560f0d5caa5@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00034.txt.bz2 On 2019-01-26 17:31, Philippe Waroquiers wrote: > Valgrind detects leaks like the following (gdb.base/macscp.exp). > This patch fixes 1 of the 3 leaks (the last one in the list below). > > The remaining leaks are better fixed in splay_tree_remove and > splay_tree_insert in libiberty. > Tested on debian/amd64, natively and under valgrind. > > ==22285== 64 (48 direct, 16 indirect) bytes in 1 blocks are definitely > lost in loss record 737 of 3,377 > ==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309) > ==22285== by 0x4049E7: xmalloc (common-utils.c:44) > ==22285== by 0x533A20: new_macro_key(macro_table*, char const*, > macro_source_file*, int) (macrotab.c:355) > ==22285== by 0x53438B: macro_define_function(macro_source_file*, > int, char const*, int, char const**, char const*) (macrotab.c:822) > ==22285== by 0x52F945: macro_define_command(char const*, int) > (macrocmd.c:409) > ... > ==22285== 128 (96 direct, 32 indirect) bytes in 2 blocks are > definitely lost in loss record 1,083 of 3,377 > ==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309) > ==22285== by 0x4049E7: xmalloc (common-utils.c:44) > ==22285== by 0x533A20: new_macro_key(macro_table*, char const*, > macro_source_file*, int) (macrotab.c:355) > ==22285== by 0x534277: > macro_define_object_internal(macro_source_file*, int, char const*, > char const*, macro_special_kind) (macrotab.c:776) > ==22285== by 0x52F7E0: macro_define_command(char const*, int) > (macrocmd.c:414) > ... > ==22285== 177 bytes in 19 blocks are definitely lost in loss record > 1,193 of 3,377 > ==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309) > ==22285== by 0x4049E7: xmalloc (common-utils.c:44) > ==22285== by 0x52F5BD: extract_identifier(char const**, int) > (macrocmd.c:316) > ==22285== by 0x52F77D: macro_define_command(char const*, int) > (macrocmd.c:355) > > This is the second version of the patch. > > Compared to first version, the changes are: > * Handled the comment of Simon to have extract_identifier returning > a unique_ptr. > * Handled the comment of Tom that suggested rather to fix one of the > leaks in splay-tree.c (which is a libiberty patch). Thanks, this LGTM with a small nit to fix: > @@ -419,7 +419,7 @@ macro_define_command (const char *exp, int > from_tty) > static void > macro_undef_command (const char *exp, int from_tty) > { > - char *name; > + gdb::unique_xmalloc_ptr name; > > if (!exp) > error (_("usage: macro undef NAME")); > @@ -428,8 +428,7 @@ macro_undef_command (const char *exp, int from_tty) > name = extract_identifier (&exp, 0); Declare name when assigning it, to avoid constructing an empty object and then assigning it. > if (! name) Could you fix this to "name == NULL" or "name == nullptr" while at it? Thanks! Simon