This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] [0/5] Types reference counting (for VLA+Python)
On Thu, 16 Apr 2009 21:32:11 +0200, Tom Tromey wrote:
> FWIW, you can get a memory leak here with CVS gdb by setting a
> convenience variable to a value whose type comes from an objfile,
> closing all the objfiles ("file"), and then assigning a new value to
> the convenience variable. In this case nothing frees the type.
There will be still many leaks like this one, more places should change
alloc_type to alloc_type_discardable and possibly also include forgotten
type_incref/type_decref. Going to patch this specific case separately.
> Jan> To be true there exist some artificial temporary types such as in
> Jan> value_cast
> [...]
> Jan> , these can be freed by this implemented garbage collecting
> Jan> infrastructure. These are already leaking in current FSF GDB;
> Jan> fix based on this framework is currently not a part of this
> Jan> patchset.
>
> Why is that? (It doesn't matter in terms of acceptance, I'm just
> curious.)
value_cast for TYPE_CODE_ARRAY has a comment:
/* FIXME-type-allocation: need a way to free this type when
we are done with it. */
because it does
create_array_type ((struct type *) NULL,
element_type,
range_type));
used for resulting ARG2. ARG2 will get freed by free_all_values but as this
new array type was not marked as reclaimable it will be leaked as permanent.
> Jan> * Should the default allocation of types (alloc_type (NULL))
> Jan> provide permanent type or a garbage collectable type?
> Jan> = Currently it creates a permanent type.
>
> Too bad the other approach didn't work out. Where do all these
> permanent types come from? Not just init_type, I gather.
For example _initialize_values() does something like init_type but using
alloc_type for it. create_array_type needs to inherit the behavior from both
its range type and the index type.
> It seems strange to have a type-crawling garbage collector *and*
> reference counting. But I suppose this is because enumerating the
> root set is tricky.
As already found there are (IMO) few places needing to allocate reclaimable
types it may be doable. Thanks for the hint, I will try to rework it or at
least verify if it is viable.
Thanks,
Jan