* Trace crash in gargabe collector to the code at fault? @ 2009-08-14 13:12 okellogg 2009-08-14 14:05 ` Andrew Haley 0 siblings, 1 reply; 9+ messages in thread From: okellogg @ 2009-08-14 13:12 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-14 13:12 Trace crash in gargabe collector to the code at fault? okellogg @ 2009-08-14 14:05 ` Andrew Haley 2009-08-14 19:28 ` Tom Tromey 2009-08-15 23:25 ` Oliver Kellogg 0 siblings, 2 replies; 9+ messages in thread From: Andrew Haley @ 2009-08-14 14:05 UTC (permalink / raw) To: okellogg; +Cc: gcc okellogg@freenet.de wrote: > 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? 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-14 14:05 ` Andrew Haley @ 2009-08-14 19:28 ` Tom Tromey 2009-08-15 23:25 ` Oliver Kellogg 1 sibling, 0 replies; 9+ messages in thread From: Tom Tromey @ 2009-08-14 19:28 UTC (permalink / raw) To: Andrew Haley; +Cc: okellogg, gcc >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes: >> I am running into crashes in ggc_collect() on compiling Andrew> The usual way to find this is to use a gdb watchpoint. Find Andrew> what object is being freed, put a breakpoing on ggc_alloc_stat Andrew> at the point the object is created, and then put a watchpoint on Andrew> the word that is being corrupted. I've also had decent results by configuring with valgrind support. Tom ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-14 14:05 ` Andrew Haley 2009-08-14 19:28 ` Tom Tromey @ 2009-08-15 23:25 ` Oliver Kellogg 2009-08-16 10:51 ` Andrew Haley 1 sibling, 1 reply; 9+ messages in thread From: Oliver Kellogg @ 2009-08-15 23:25 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc 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: $ gdb /usr/src/packages/BUILD/gcc-build/gcc/gnat1 GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs [...] (gdb) catch exception Catchpoint 1: all Ada exceptions (gdb) run -g -I../../isf_pmc_interface/libsrc/ada -I../../isf_pmc_interface/spv/ada <further options> <ada sourcefiles> Apc.Init Apc.Init.B_1 Apc.Init.B_1.Pos_Io.Get Apc.Init.B_1.Pos_Io.Get Apc.Init.B_1.Pos_Io.Get Apc.Init.B_1.Pos_Io.Put Apc.Init.B_1.Pos_Io.Put Apc.Init.B_1.Pos_Io.Put {GC 17511k -> 17346k} {GC 17348k -> 17340k} {GC 17341k -> 17341k} {GC 17343k -> 17342k} {GC 17344k -> 17343k} Analyzing compilation unit {GC 17423k -> 17382k} {GC 17382k -> 17382k} {GC 17395k -> 17393k} {GC 17393k -> 17393k} {GC 17394k -> 17394k} {GC 17394k -> 17394k} {GC 17395k -> 17395k} {GC 17395k -> 17395k} {GC 17402k -> 17399k} {GC 17399k -> 17399k} {GC 17405k -> 17403k} {GC 17403k -> 17403k} {GC 17409k -> 17407k} {GC 17407k -> 17407k} {GC 17409k -> 17408k} {GC 17408k -> 17408k} {GC 17408k -> 17403k} {GC 17403k -> 17403k}Performing interprocedural optimizations <visibility> {GC 17403k -> 17403k} <many further GC messages> {GC 34561k -> +===========================GNAT BUG DETECTED==============================+ | 4.5.0 20090815 (experimental) (i686-pc-linux-gnu) GCC error: | | in validate_free_objects, at ggc-page.c:1888 | | Error detected around ../../isf_pmc_interface/spv/ada/basic_types.ads:140:26| | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | | Use a subject line meaningful to you and us to track the bug. | | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==========================================================================+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). [...] Catchpoint 1, TYPES.UNRECOVERABLE_ERROR at <__gnat_debug_raise_exception> (e=0x8ddfd3c) at ../../../SOURCES/gcc/gcc/ada/s-except.adb:44 44 end Debug_Raise_Exception; Current language: auto; currently ada (gdb) bt #0 <__gnat_debug_raise_exception> (e=0x8ddfd3c) at ../../../SOURCES/gcc/gcc/ada/s-except.adb:44 #1 0x081ca713 in <__gnat_raise_nodefer_with_msg> (e=0x8ddfd3c) at ../../../SOURCES/gcc/gcc/ada/a-except.adb:800 #2 0x081cb0a9 in <__gnat_raise_exception> (e=0x8ddfd3c, message=0x0) at ../../../SOURCES/gcc/gcc/ada/a-except.adb:839 #3 0x081fd422 in comperr.compiler_abort (x=0x9813b90, code=-1, fallback_loc=0x9813bc8) at ../../../SOURCES/gcc/gcc/ada/comperr.adb:415 #4 0x0818401c in internal_error_function (msgid=0x8ccfa23 "in %s, at % s:%d["00"]", ap=0xbfffc71c) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/misc.c:372 #5 0x0857a754 in diagnostic_report_diagnostic (context=0x92d0bc0, diagnostic=0xbfffc720) at ../../../SOURCES/gcc/gcc/diagnostic.c:406 #6 0x0857adfe in internal_error (gmsgid=0x8ccfa23 "in %s, at %s:% d["00"]") at ../../../SOURCES/gcc/gcc/diagnostic.c:676 #7 0x0857aed3 in fancy_abort (file=0x8cc422c "../../../SOURCES/gcc/gcc/ggc-page.c["00"]", line=1888, function=0x8cc42bc "validate_free_objects["00"]") at ../../../SOURCES/gcc/gcc/diagnostic.c:730 #8 0x0851163c in validate_free_objects () at ../../../SOURCES/gcc/gcc/ggc-page.c:1888 #9 0x085117ab in ggc_collect () at ../../../SOURCES/gcc/gcc/ggc-page.c:1949 #10 0x089357e2 in cgraph_finalize_function (decl=0xb56de600, nested=0 '["00"]') at ../../../SOURCES/gcc/gcc/cgraphunit.c:550 #11 0x0818886b in end_subprog_body (body=0xb570c5cc) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/utils.c:2116 #12 0x081ba1ae in Subprogram_Body_to_gnu (gnat_node=571248) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:2339 #13 0x081c0d42 in gnat_to_gnu (gnat_node=571248) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:4792 #14 0x081c4bc2 in process_decls (gnat_decls=-99950950, gnat_decls2=0, gnat_end_list=0, pass1p=0 '["00"]', pass2p=1 '["01"]') at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:6306 #15 0x081c4cba in process_decls (gnat_decls=-99984793, gnat_decls2=0, gnat_end_list=0, pass1p=1 '["01"]', pass2p=1 '["01"]') at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:6316 #16 0x081c0dd9 in gnat_to_gnu (gnat_node=146150) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:4812 #17 0x081c0d8d in gnat_to_gnu (gnat_node=147256) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:4806 #18 0x081bc788 in Compilation_Unit_to_gnu (gnat_node=146130) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:3387 #19 0x081b5769 in gigi (gnat_root=146130, max_gnat_node=1140983, number_name=125936, nodes_ptr=0xb1af3008, next_node_ptr=0xb5a8c008, prev_node_ptr=0xb6cf6008, elists_ptr=0x96b5a90, elmts_ptr=0xb7b39008, strings_ptr=0x966f9b8, string_chars_ptr=0xb66c2008, list_headers_ptr=0xb73ea008, number_file=208, file_info_ptr=0xbfffd400, standard_boolean=12, standard_integer=27, standard_long_long_float=67, standard_exception_type=1225, gigi_operating_mode=0, main_unit_number=38) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:629 #20 0x0850a93a in back_end.call_back_end (mode=generate_object) at ../../../SOURCES/gcc/gcc/ada/back_end.adb:100 #21 0x0850c79e in gnat1drv () at ../../../SOURCES/gcc/gcc/ada/gnat1drv.adb:1002 #22 0x08183a0f in gnat_parse_file (set_yydebug=0) at ../../../SOURCES/gcc/gcc/ada/gcc-interface/misc.c:167 #23 0x08794eda in compile_file () at ../../../SOURCES/gcc/gcc/toplev.c:1032 #24 0x08796d1b in do_compile () at ../../../SOURCES/gcc/gcc/toplev.c:2387 #25 0x08796e46 in toplev_main (argc=98, argv=0xbfffe004) at ../../../SOURCES/gcc/gcc/toplev.c:2445 #26 0x0850fe2e in main (argc=1836016485, argv=0x72726570) at ../../../SOURCES/gcc/gcc/main.c:35 (gdb) up 8 #8 0x0851163c in validate_free_objects () at ../../../SOURCES/gcc/gcc/ggc-page.c:1888 1888 gcc_assert (!(pe->in_use_p[word] & (1UL << bit))); Current language: auto; currently c (gdb) p f->object $1 = (void *) 0xb7fd6138 (gdb) watch 0xb7fd6138 Watchpoint 2: 3086836024 (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/src/packages/BUILD/gcc-build/gcc/gnat1 -g -I../../isf_pmc_interface/libsrc/ada -I../../isf_pmc_interface/spv/ada -I../../isf_pmc_interface/spv/spv_client -I../common_simple -I../cs/dchdl/dchdlsw -I../cs/dchdl/dchdlsw_link16 -I../cs/dchdl/dchdlsw_llapi -I../cs/dchdl/link_16_general -I../cs/dchdl/message_sequence -I../cs/dchdl/tcp_ip -I../cs/lrm/scserv -I../cs/rtdh -I../eo/anmeldung -I../eo/apc -I../eo/apc/corba -I../eo/apc/corba/dev_ctrl -I../eo/apc/socket_if -I../eo/apc/container -I../eo/apc/identification -I../eo/asmc/new_mapman_client/spv_client -I../eo/asmc/new_mapman_client/standard_routines -I../eo/asmc/real_asmc -I../eo/as_control -I../eo/as_type_conversions -I../eo/coordinate_routines_ss -I../eo/eo_main -I../eo/fsm -I../eo/general_utilities_ss -I../eo/general_utilities_ss/geometries -I../eo/general_utilities_ss/wgs84_conv -I../eo/isf -I../eo/jsm -I../eo/llapi_types -I../eo/protocol_handler -I../eo/protocol_handler/tcp_ip -I../eo/protocol_handler/track_transmit -I../eo/samocdef -I../eo/samocdef/tbm_samoc -I../eo/socbpv -I../eo/socbpv/db_handler -I../eo/socmapman -I../eo/socmapman/spv -I../eo/eommi/ -I../eo/eommi/oi/ -I../eo/eommi/oi/mmi_interface_definition/ -I../eo/eommi/oi_project/ -I../eo/eommi/oi/oix_oi_interface_definition/ -I../eo/eommi/oi/oix_to_oi_interface_implementation/socket_layer/ -I../eo/eommi/oi/oi_core/views/ -I../eo/eommi/oi/oi_core/ -I../eo/eommi/oi/oi_core/zyklop/ -I../eo/eommi/oi/oi_core/models/ -I../eo/eommi/oi/oi_core/controller/ -I../eo/eommi/oi/oi_core/views/geographical_views/ -I../eo/eommi/oi/oi_to_oix_interface_proxy/ -I../eo/eommi/oi_project/extern_to_mmi_interface_implementation/spv_layer/ -I../eo/eommi/oi_project/extern_to_mmi_interface_implementation/netman_layer/ -I../eo/eommi/oi_project/mmi_to_extern_interface_proxy/ -I../eo/eommi/oi/mmi_interface_definition/to_extern_interface_definition/ -I../eo/eommi/oi/mmi_interface_definition/to_mmi_interface_definition/ -I../sysman/bridge -I../sysman/corba -I../sysman/eas -I../sysman/lrec -I../sysman/lrm/lrm_swe_ada -I../sysman/netman -I../sysman/port -I../sysman/syspro -I../sysman/top -I../mathlibs -I../cs/dchdl/dchdlsw_link22 -I../eo/link22 -I- /home/okellogg/ada/mdlp/binsrc/eo/apc/apc.adb /home/okellogg/ada/mdlp/isf_pmc_interface/spv/ada/basic_types.ads /home/okellogg/ada/mdlp/binsrc/cs/dchdl/dchdlsw/dchdl.adb /home/okellogg/ada/mdlp/binsrc/eo/anmeldung/eomain_anmeldung.adb /home/okellogg/ada/mdlp/binsrc/sysman/port/exception_output.adb /home/okellogg/ada/mdlp/binsrc/eo/link22/fsm_rx_receive.adb /home/okellogg/ada/mdlp/binsrc/eo/socbpv/grunddaten.adb /home/okellogg/ada/mdlp/binsrc/cs/dchdl/dchdlsw_link16/l16_dchdl_j28_2_text_message.ads /home/okellogg/ada/mdlp/binsrc/cs/dchdl/dchdlsw_link16/link16_dchdl.adb /home/okellogg/ada/mdlp/binsrc/cs/dchdl/dchdlsw_link22/link22_dchdl.adb /home/okellogg/ada/mdlp/binsrc/eo/apc/corba/milipos_interface.adb /home/okellogg/ada/mdlp/binsrc/sysman/syspro/p_dialog.adb /home/okellogg/ada/mdlp/binsrc/cs/dchdl/dchdlsw_llapi/p_llapi.adb /home/okellogg/ada/mdlp/binsrc/sysman/lrec/p_monserv.adb /home/okellogg/ada/mdlp/binsrc/cs/dchdl/dchdlsw/p_prot_automa.adb /home/okellogg/ada/mdlp/binsrc/cs/rtdh/p_rtdhcnf_as.adb /home/okellogg/ada/mdlp/binsrc/cs/rtdh/p_rtdhcnf_db.adb /home/okellogg/ada/mdlp/binsrc/cs/rtdh/p_rtdhcnf_dchdl.adb /home/okellogg/ada/mdlp/binsrc/eo/protocol_handler/protocol_handler.adb /home/okellogg/ada/mdlp/binsrc/sysman/port/retrieve_exception.ads /home/okellogg/ada/mdlp/isf_pmc_interface/spv/spv_client/spv_mgmt.adb /home/okellogg/ada/mdlp/binsrc/sysman/corba/strings.adb /home/okellogg/ada/mdlp/binsrc/sysman/corba/unix.adb Program received signal SIGTRAP, Trace/breakpoint trap. 0xb7fe0852 in ?? () from /lib/ld-linux.so.2 And now I'm getting lots of these SIGTRAP signals in gdb. So first question is: Did I use the "watch" command in the right way? And if so, why is gdb giving me all these SIGTRAPs? Thanks again, Oliver ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-15 23:25 ` Oliver Kellogg @ 2009-08-16 10:51 ` Andrew Haley 2009-08-28 18:04 ` Oliver Kellogg 0 siblings, 1 reply; 9+ messages in thread From: Andrew Haley @ 2009-08-16 10:51 UTC (permalink / raw) To: okellogg; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-16 10:51 ` Andrew Haley @ 2009-08-28 18:04 ` Oliver Kellogg 2009-08-28 21:12 ` Ian Lance Taylor 0 siblings, 1 reply; 9+ messages in thread From: Oliver Kellogg @ 2009-08-28 18:04 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-28 18:04 ` Oliver Kellogg @ 2009-08-28 21:12 ` Ian Lance Taylor 2009-08-31 4:57 ` Oliver Kellogg 0 siblings, 1 reply; 9+ messages in thread From: Ian Lance Taylor @ 2009-08-28 21:12 UTC (permalink / raw) To: okellogg; +Cc: Andrew Haley, gcc oliver.kellogg@t-online.de (Oliver Kellogg) writes: > 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.) I believe that as long we have a garbage collector, ggc_free should be used very very rarely, only when there is clear evidence that it reduces memory usage. If you just want to stop referring to memory, you should simply set the pointer to NULL. There is no point to having a garbage collector if we don't take advantage of it. Ian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-28 21:12 ` Ian Lance Taylor @ 2009-08-31 4:57 ` Oliver Kellogg 2009-08-31 14:41 ` Tom Tromey 0 siblings, 1 reply; 9+ messages in thread From: Oliver Kellogg @ 2009-08-31 4:57 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: tromey, gcc On Fri, 2009-08-28 at 06:58 -0700, Ian Lance Taylor wrote: > oliver.kellogg@t-online.de (Oliver Kellogg) writes: > > > 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.) > > I believe that as long we have a garbage collector, ggc_free should be > used very very rarely, only when there is clear evidence that it reduces > memory usage. If you just want to stop referring to memory, you should > simply set the pointer to NULL. There is no point to having a garbage > collector if we don't take advantage of it. > > Ian As mentioned, I'm still struggling with leftovers being carried over from compilation 1 to N-1 into compilation N of a compile job. gcc_free'ing things (in combination with "configure --enable-checking=gc,gcac") helps me track down objects that should have been reset. When the files of a compile job are disjoint (i.e. they do not share common declarations) then IMHO freeing really makes sense. Also I believe that this exercise will help me learn more about GCC internals. Once the multi source compilation is working in this mode, with complete reset of all backend artefacts before compiling a file of a compile job, then I might look at freeing things more intelligently, e.g. freeing only the artefacts that correspond to non-inlined functions and file-local declarations but leaving the trees for globally visible declarations intact for reuse by the compilation of further files of the compile job. A next step after that may be to look at Tom Tromey's incremental- compiler branch and see whether it is possible to integrate my changes there. I would be looking at running the incremental compiler in a serverless mode more similar to the way GCC works now, where trees are constructed and shared only within a single compile job (i.e. the backend is called only once but with many files as the argument list, and the trees are only reused throughout the compilations of these files but do not continue to exist beyond the backend invocation lifetime.) Oliver ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Trace crash in gargabe collector to the code at fault? 2009-08-31 4:57 ` Oliver Kellogg @ 2009-08-31 14:41 ` Tom Tromey 0 siblings, 0 replies; 9+ messages in thread From: Tom Tromey @ 2009-08-31 14:41 UTC (permalink / raw) To: okellogg; +Cc: Ian Lance Taylor, gcc >>>>> "Oliver" == Oliver Kellogg <oliver.kellogg@t-online.de> writes: Oliver> As mentioned, I'm still struggling with leftovers being carried Oliver> over from compilation 1 to N-1 into compilation N of a compile Oliver> job. gcc_free'ing things (in combination with "configure Oliver> --enable-checking=gc,gcac") helps me track down objects that Oliver> should have been reset. This is ok as an approach to development but probably not ok for a real patch. If you look on the incremental branch you can find various places where I added new functions to clean up modules before a new compilation job is run. This fills a similar need, if I understand your problem correctly. I did this in an ad hoc way, just resetting the modules I needed, so I don't know whether or not the particular changes will be of use to you. Oliver> A next step after that may be to look at Tom Tromey's Oliver> incremental- compiler branch and see whether it is possible to Oliver> integrate my changes there. I would be looking at running the Oliver> incremental compiler in a serverless mode more similar to the Oliver> way GCC works now, where trees are constructed and shared only Oliver> within a single compile job (i.e. the backend is called only Oliver> once but with many files as the argument list, and the trees are Oliver> only reused throughout the compilations of these files but do Oliver> not continue to exist beyond the backend invocation lifetime.) This sounds like the --combine switch on trunk. The incremental compiler work is mostly orthogonal to --combine. The C front end changes improve --combine performance, and I used --combine as a testbed, but I didn't touch the --combine infrastructure itself. (I think these changes would help with LIPO, too, but I haven't really looked into it.) If you wanted your modified compiler to emit separate object files for a --combine run, then yeah, you would need something like a hybrid between the compile server from the incremental branch and --combine. This is doable, maybe even easy. Tom ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-08-30 16:12 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-08-14 13:12 Trace crash in gargabe collector to the code at fault? okellogg 2009-08-14 14:05 ` Andrew Haley 2009-08-14 19:28 ` Tom Tromey 2009-08-15 23:25 ` Oliver Kellogg 2009-08-16 10:51 ` Andrew Haley 2009-08-28 18:04 ` Oliver Kellogg 2009-08-28 21:12 ` Ian Lance Taylor 2009-08-31 4:57 ` Oliver Kellogg 2009-08-31 14:41 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).