This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Trace crash in gargabe collector to the code at fault?
It turned out to be the following:
In multi source compile mode, I ggc_free() the data in dwarf2out.c after
code generation for a file is done. (I found that I need this because
otherwise the assembly code generated for file_2 to file_N of a compile
job will carry leftovers from the code generated for file_1.)
This includes freeing the comp_unit_die. However, struct tree_type
(tree.h) contains a union tree_type_symtab which has a member `die', and
this may point to the comp_unit_die.
gigi (ada/gcc-interface/trans.c) does not ggc_free the trees it
allocates, therefore these trees continue to be alive even when the
comp_unit_die was freed. So I guess I need to set TYPE_SYMTAB_DIE(t) to
NULL on all nodes before freeing comp_unit_die. To be verified now.
Thanks again Andrew.
Oliver
On Sat, 2009-08-15 at 20:00 +0100, Andrew Haley wrote:
> Oliver Kellogg wrote:
> > On Fri, 2009-08-14 at 10:41 +0100, Andrew Haley wrote:
> >>> I am stuck here, i.e. I don't know how to find the code
> >>> that is
> >>> at fault.
> >>> Is there some way to trace a pointer entered in
> >>> G.free_object_list
> >>> back to its origin in the code?
> >> The usual way to find this is to use a gdb watchpoint. Find what object is
> >> being freed, put a breakpoing on ggc_alloc_stat at the point the object is
> >> created, and then put a watchpoint on the word that is being corrupted.
> >>
> >> Andrew.
> >
> > Thanks.
> > I tried as follows:
>
> That's not gonna work.
>
> Put a breakpoint at the end of ggc_alloc_stat. It'll have to be a
> conditional breakpoint on the address of the node that's being corrupted.
>
> When the object is created, add the watchpoint.
>
> Andrew.