From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105117 invoked by alias); 28 Jun 2016 14:40:08 -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 105090 invoked by uid 89); 28 Jun 2016 14:40:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=qiyaoltc@gmail.com, qiyaoltcgmailcom, U*qiyaoltc, sk:qiyaolt X-HELO: gproxy9-pub.mail.unifiedlayer.com Received: from gproxy9-pub.mail.unifiedlayer.com (HELO gproxy9-pub.mail.unifiedlayer.com) (69.89.20.122) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Tue, 28 Jun 2016 14:39:57 +0000 Received: (qmail 6016 invoked by uid 0); 28 Jun 2016 14:39:54 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 28 Jun 2016 14:39:54 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw4 with id CEfq1t01H2f2jeq01Eftmg; Tue, 28 Jun 2016 08:39:54 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=PnD2wP_eR3oA:10 a=7XZj0uCbPdcA:10 a=pD_ry4oyNxEA:10 a=pGLkceISAAAA:8 a=zstS-IiYAAAA:8 a=jDKxhiD8AjSe1XswoIMA:9 a=6kGIvZw6iX1k4Y-7sg4_:22 a=4G6NA9xxw8l3yy4pmD5M:22 Received: from [75.171.172.174] (port=51634 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_2) (envelope-from ) id 1bHuB4-00008d-Gs; Tue, 28 Jun 2016 08:39:50 -0600 From: Tom Tromey To: Yao Qi Cc: Tom Tromey , "gdb-patches\@sourceware.org" Subject: Re: [RFA] PR gdb/17210 - fix possible memory leak in read_memory_robust References: <1465490013-15336-1-git-send-email-tom@tromey.com> Date: Tue, 28 Jun 2016 14:40:00 -0000 In-Reply-To: (Yao Qi's message of "Tue, 28 Jun 2016 11:42:46 +0100") Message-ID: <87oa6lidhq.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {36111:box522.bluehost.com:elynrobi:tromey.com} {sentby:smtp auth 75.171.172.174 authed with tom+tromey.com} X-Exim-ID: 1bHuB4-00008d-Gs X-Source-Sender: (pokyo) [75.171.172.174]:51634 X-Source-Auth: tom+tromey.com X-Email-Count: 0 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2016-06/txt/msg00464.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> On Thu, Jun 9, 2016 at 5:33 PM, Tom Tromey wrote: >> >> VEC(memory_read_result_s) * >> @@ -1810,6 +1810,8 @@ read_memory_robust (struct target_ops *ops, >> { >> VEC(memory_read_result_s) *result = 0; >> int unit_size = gdbarch_addressable_memory_unit_size (target_gdbarch ()); >> + struct cleanup *cleanup = make_cleanup (free_memory_read_result_vector, >> + &result); >> Yao> result is a local variable on stack, so its address is meaningless when the Yao> exception is throw, because the stack has already been destroyed. Yao> Probably, we can register cleanup for result once it becomes to non-NULL, Yao> and changes in free_memory_read_result_vector are not needed. I don't think that will work, because resizing the vector may cause the value to change. Though one option would be to discard the cleanup and recreate it after each push. Tom