This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Trace crash in gargabe collector to the code at fault?


Working on the GNAT multi-source compile feature

(see http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html),

I am running into crashes in ggc_collect() on compiling

the 2nd file in the compile job.



Following the advice given in
http://gcc.gnu.org/ml/gcc/2004-04/msg00901.html ,
I configured GCC with --enable-gcac.

As a result, the crash no longer happens in ggc-page.c
function
lookup_page_table_entry (at the line "return
base[L1][L2];") but
instead happens in validate_free_objects, at the line

 /* Make certain it isn't visible from any root. Notice
that we
 do this check before sweep_pages merges save_in_use_p. */
 gcc_assert (!(pe->in_use_p[word] & (1UL << bit)));

The backtrace using trunk 20090807 is:
#7 0x0852f5bf in fancy_abort (file=0x8c734ca
"../../gcc/gcc/ggc-page.c["00"]", line=1888, 
 function=0x8c7354f "validate_free_objects["00"]") at
../../gcc/gcc/diagnostic.c:730
#8 0x084c5d5b in validate_free_objects () at
../../gcc/gcc/ggc-page.c:1888
#9 0x084c5ec7 in ggc_collect () at
../../gcc/gcc/ggc-page.c:1949
#10 0x088eb317 in cgraph_finalize_function
(decl=0xb6824e00, nested=0 '["00"]') at
../../gcc/gcc/cgraphunit.c:550
#11 0x087403fe in finalize_size_functions () at
../../gcc/gcc/stor-layoutc:366
#12 0x088ec3c5 in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1034
#13 0x08167a73 in gnat_write_global_declarations () at
../../gcc/gcc/ada/gcc-interface/utils.c:4671
#14 0x0874a198 in compile_file () at
../../gcc/gcc/toplev.c:1044
#15 0x0874bfd4 in do_compile () at
../../gcc/gcc/toplev.c:2387
#16 0x0874c0f0 in toplev_main (argc=25, argv=0xbfe6faa4) at
../../gcc/gcc/toplev.c:2445
#17 0x084c460a in main (argc=148423232, argv=0x8c105b0) at
../../gcc/gcc/main.c:35

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?

Thanks,

Oliver






Heute schon ge"freeMail"t?
Jetzt kostenlose E-Mail-Adresse sichern!
http://email.freenet.de/dienste/emailoffice/produktuebersicht/basic/mail/index.html?pid=6831


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