This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: TYPE_NAME memory management
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, gdb at sourceware dot org
- Date: Fri, 4 Sep 2009 15:43:51 -0700
- Subject: Re: TYPE_NAME memory management
- References: <e394668d0909041417x3e65c584v7633e188bbdf4d6e@mail.gmail.com>
> Sometimes it's a string constant, sometimes it's in malloc space,
> sometimes it's on objfile's obstack, and now sometimes it can live in
> mmap'd space.
My understanding was that, if the type belongs to an objfile, then
the type name should be allocated on the objfile obstack. I know we
have types that do not belong to objfiles (types that are duplicated
from objfile types in order to preserve a value from the value history,
or gdbarch types; any others?), and these types are allocated on the
heap, including the type name, but I don't think we ever deallocate
these types.
Perhaps we might want to review all TYPE_NAME and TYPE_TAG_NAME
assignments. If there is a memory leak due to an incorrect malloc,
we might want to fix that too.
> [...] except for the new mmap'd values, so it seems like the thing to
> do for now is copy such strings onto the objfile's obstack.
This sounds right.
> I'm not sure what the speed loss will be, but I think it's the thing
> to do pending data that says something more clever is needed.
Agreed - correctness before speed :)
--
Joel