* Freeing memory allocated in the inferior
@ 2017-02-20 10:12 Matthew Malcomson
2017-02-20 17:58 ` Simon Marchi
0 siblings, 1 reply; 2+ messages in thread
From: Matthew Malcomson @ 2017-02-20 10:12 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Freeing memory allocated in the inferior
2017-02-20 10:12 Freeing memory allocated in the inferior Matthew Malcomson
@ 2017-02-20 17:58 ` Simon Marchi
0 siblings, 0 replies; 2+ messages in thread
From: Simon Marchi @ 2017-02-20 17:58 UTC (permalink / raw)
To: Matthew Malcomson; +Cc: gdb
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-02-20 17:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-20 10:12 Freeing memory allocated in the inferior Matthew Malcomson
2017-02-20 17:58 ` Simon Marchi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox