Trace crash in gargabe collector to the code at fault?

Trace crash in gargabe collector to the code at fault?

[okellogg]

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

Re: Trace crash in gargabe collector to the code at fault?

[Andrew Haley]

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.

Re: Trace crash in gargabe collector to the code at fault?

[Tom Tromey]

>>>>> "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

Re: Trace crash in gargabe collector to the code at fault?

[Oliver Kellogg]

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

Re: Trace crash in gargabe collector to the code at fault?

[Andrew Haley]

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.

Re: Trace crash in gargabe collector to the code at fault?

[Oliver Kellogg]

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.

Re: Trace crash in gargabe collector to the code at fault?

[Ian Lance Taylor]

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

Re: Trace crash in gargabe collector to the code at fault?

[Oliver Kellogg]

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

Re: Trace crash in gargabe collector to the code at fault?

[Tom Tromey]

>>>>> "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