Re: [archer-jankratochvil-vla] check_typedef() memory leak

[Tom Tromey <tromey at redhat dot com>]

Tom> I think the user will be able to construct a function type whose
Tom> argument types span objfiles, which is disallowed.  

Jan> GDB already creates types referencing both a real objfile and
Jan> NULL objfile (for internal type) at least in
Jan> read_tag_string_type().  The question is whether (1) GC should
Jan> cope with it or (2) whether internal types should get duplicated
Jan> for references or (3) internal types should be differentiated
Jan> from malloc-created types.

Yeah.

Spanning a real objfile and the NULL objfile is "ok", because types
allocated using the NULL objfile are never freed in cvs gdb.

This was ok-ish when the types were just used for the value history --
there weren't that many of them, and they weren't really leaked, since
you could always get at them via the history.

The issue with function types is different.  If we modify the C parser
to preserve function argument types, then the user can construct a
type that spans two real objfiles.  This can easily lead to gdb
crashes when one of the objfiles is deleted -- preserve_one_value does
not handle this case (and neither does the type-copying code in
gdb.Type).

I suppose we could work out a way to have preserve_one_value handle
objfile-spanning types, and then do type GC only on NULL-objfile types.
This may preserve the "fast freeing" quality of the current approach.

I think we will still need a real GC.  If we fix PR 9608, then the
user will be able to create a type that violates the current reference
counting constraints.  And, in the future we may want to let the
Python programmer create other new types dynamically.

Another option is to continue to leak NULL objfile types.  However, I
am not fond of this, because I would like the future
python-scriptable, multi-inferior gdb to be a robust long-running
application.  Memory leaks are intolerable in this scenario.

I don't plan to work on type GC in the near future.  I am interested
in coming up with a plan for it, though.

Tom