Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Matthew Malcomson <hardenedapple@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Freeing memory allocated in the inferior
Date: Mon, 20 Feb 2017 17:58:00 -0000	[thread overview]
Message-ID: <9b70fd7b63635e4132f244bac978b810@polymtl.ca> (raw)
In-Reply-To: <6e28ebac-e4de-871a-0b7e-1fef46fc4faf@gmail.com>

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.


      reply	other threads:[~2017-02-20 17:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 10:12 Matthew Malcomson
2017-02-20 17:58 ` Simon Marchi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9b70fd7b63635e4132f244bac978b810@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb@sourceware.org \
    --cc=hardenedapple@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox