This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 23 Dec 2008 17:47:09 +0100, Tom Tromey wrote:
> This week I have been thinking that this patch is not nearly enough,
> even for the relatively near future.

Its basic idea is that the whole MAIN_TYPE tree (such as `int[][]' producing
array(+range)-array(+range)-int) and all the instances of TYPEs
(const/non-const etc.) referencing each MAIN_TYPE should be freed together.

Which is IMO right.  This freeing just needs to be called (also) from GC.


> There aren't many good options for fixing this that don't introduce memory
> leaks; maybe just a full type GC.

DW_FORM_block* requires generating completely new (constant) MAIN_TYPEs by
check_typedef() and as check_typedef() is called arbitrarily across GDB
forgetting its results GC is required there.  VALUE already has a GC there
- free_all_values()+release_value().

New MAIN_TYPEs must not be linked with the original DW_FORM_block* type as
stepping `void f(int l){char a[l];} for (i=0;;i++) f(i);' would severely leak.


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

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


Thanks,
Jan


On Tue, 23 Dec 2008 17:47:09 +0100, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> archer.vla: Fighting the memory leak using Tom's <type> reference counting.
> 
> This week I have been thinking that this patch is not nearly enough,
> even for the relatively near future.
> 
> E.g., consider http://sourceware.org/bugzilla/show_bug.cgi?id=9608
> This bug is that gdb forgets parameter types in casts to function:
> 
> (gdb) whatis int (*)(double, double)
> type = int (*)()
> 
> ... it should say:
> 
> type = int (*)(double, double)
> 
> 
> We can fix the immediate bug without too much trouble -- but if we do
> I think the user will be able to construct a function type whose
> argument types span objfiles, which is disallowed.  There aren't many
> good options for fixing this that don't introduce memory leaks; maybe
> just a full type GC.
> 
> Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]