From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55825 invoked by alias); 20 Feb 2017 17:58:01 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 55754 invoked by uid 89); 20 Feb 2017 17:58:00 -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,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=Freeing, H*f:sk:6e28eba, H*i:sk:6e28eba, HX-PHP-Originating-Script:rcube.php X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Feb 2017 17:57:56 +0000 Received: by simark.ca (Postfix, from userid 33) id 490EA1E18F; Mon, 20 Feb 2017 12:57:54 -0500 (EST) To: Matthew Malcomson Subject: Re: Freeing memory allocated in the inferior X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 20 Feb 2017 17:58:00 -0000 From: Simon Marchi Cc: gdb@sourceware.org In-Reply-To: <6e28ebac-e4de-871a-0b7e-1fef46fc4faf@gmail.com> References: <6e28ebac-e4de-871a-0b7e-1fef46fc4faf@gmail.com> Message-ID: <9b70fd7b63635e4132f244bac978b810@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.3 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00046.txt.bz2 On 2017-02-20 05:11, Matthew Malcomson wrote: > Hello, > > I've just been reading the code, and was hoping someone could help me > understand something. > > It seems that memory allocated in the inferior (with > `value_allocate_space_in_inferior()` is never freed, even when the gdb > process exits/detaches. > > Is this true (i.e. have I missed something)? > I found an old comment on an old bug that implies this is correct > https://sourceware.org/bugzilla/show_bug.cgi?id=16236#c1, and the > pointer appears to remain valid in the inferior over a lot of > allocation after detaching, but neither of those are particularly > conclusive. > > If so, why is this? > > I can see it would be difficult to know when to free them during > execution, because the user may simply remember the pointer address > the variable is stored and attempt to use it, but what about storing > the allocations on a data structure somewhere, and freeing them when > gdb is closing/detaching? > I doubt many users are remembering pointer addresses after having > detached and attached again to a process, but I guess there could be > an extra `set` parameter introduced if this were the case. The memory could be needed even after gdb exits/detaches. Consider the case where you use gdb to insert a string in some data structure and detach from the inferior to let it run freely. If gdb frees the memory containing the string, the data structure will contain an invalid pointer.