Re: [patch] [0/5] Types reference counting (for VLA+Python)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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