From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38315 invoked by alias); 18 Oct 2017 03:32:26 -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 38306 invoked by uid 89); 18 Oct 2017 03:32:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=risk X-HELO: outbound-ss-1812.hostmonster.com Received: from gproxy1-pub.mail.unifiedlayer.com (HELO outbound-ss-1812.hostmonster.com) (69.89.25.95) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Oct 2017 03:32:25 +0000 Received: from CMOut01 (cmgw2 [10.0.90.82]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 9699B175B73 for ; Tue, 17 Oct 2017 21:32:23 -0600 (MDT) Received: from box522.bluehost.com ([74.220.219.122]) by CMOut01 with id NrYL1w00C2f2jeq01rYPvK; Tue, 17 Oct 2017 21:32:23 -0600 X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=02M-m0pO-4AA:10 a=pGLkceISAAAA:8 a=WAlAh8Vx3j3X2yLFIzMA:9 Received: from 184-96-33-178.hlrn.qwest.net ([184.96.33.178]:53600 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1e4f5g-0012nX-10; Tue, 17 Oct 2017 21:32:20 -0600 From: Tom Tromey To: Yao Qi Cc: Simon Marchi , Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 4/8] Make strip_bg_char return a unique_xmalloc_ptr References: <20171013205950.22943-1-tom@tromey.com> <20171013205950.22943-5-tom@tromey.com> <86shejwi6t.fsf@gmail.com> <88e7166cfba4e631a91a6a34d864d354@polymtl.ca> <867evuvxug.fsf@gmail.com> Date: Wed, 18 Oct 2017 03:32:00 -0000 In-Reply-To: <867evuvxug.fsf@gmail.com> (Yao Qi's message of "Tue, 17 Oct 2017 12:05:11 +0100") Message-ID: <87o9p5rv0h.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1e4f5g-0012nX-10 X-Source-Sender: 184-96-33-178.hlrn.qwest.net (bapiya) [184.96.33.178]:53600 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes X-SW-Source: 2017-10/txt/msg00544.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> Yes, that is one approach I though of, but it needs changing code. I am Yao> looking at running gdb testsuite with valgrind, but there are too many Yao> warnings on leak, so it is not that useful to find new leaks. That sounds pretty bad. A valgrind or ASAN buildbot would be good... Yao> The patch is the good direction to go, so I don't want to block it. Yao> Meanwhile, I am still looking at memory leaks reported by valgrind. I don't know if the cleanup checker still works, but that would be one route. I don't believe there are all that many dangling cleanups any more, but I do agree that it's hard to know. It's maybe worth pointing out that, at least in the past (I didn't look recently), commands were always run with a cleanup installed, and this cleanup was run after the command returned. So, before the cleanup checker work, it was normal to see dangling cleanups in command implementations. If this still exists then I think it would reduce the risk of changing strip_bg_char. Tom