[Bug debug/31230] debug information depends on gc parameters

[Bug debug/31230] debug information depends on gc parameters

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
r0-101483-g5c9fae0d6eee58 removed the TYPE_SYMTAB_POINTER part of
type_hash_marked_p .

I have no idea if the rest still applies. Plus stabs debugging has been removed
in GCC 13.

[Bug debug/31230] debug information depends on gc parameters

[tjvries at xs4all dot nl]

------- Comment #5 from tjvries at xs4all dot nl  2010-06-21 10:32 -------
Created an attachment (id=20954)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20954&action=view)
naive patch. run callbacks on hashtable entries exhaustively before deleting

Furthermore, I investigated why this problem does not occur with 4.4.0 onwards,
and I found that this is due to the fact that -funit-at-a-time is hard coded to
on for 4.4.0, which causes f1 to be live at the same time as f3 (no
cgraph_release_function_body() in between). An easy workaround for this problem
in 4.3.5 is therefore -funit-at-a-time.

I also managed to reproduce the problem for -gstabs. The patch from comment 3
works indeed, but not for -gstabs, which makes a lot of sense since the patch
is dwarf specific. Of course we might attempt to fix the stab format (and
possible others) in a similar way, but the fact that the fix needs to be
repeated made me wonder whether the problem had to be dealt with at another
level than specific debug formats.

Let's take a look at what happens exactly during garbage collection in between
f1 and f3 in mark_roots():
- gt_ggc_rtab is traversed, and neither array type nor index type is marked
live
- gt_ggc_cache_rtab is traversed, in particular type_hash_table, and the hash
entry with the index type is hit (before the entry with the array type, but
this is non-deterministic) and processed by ggc_htab_delete(). The entry is not
considered live, and consequently the entry is cleared.
- next the entry with the array type is hit and processed by ggc_htab_delete().
The entry is considered live due to TYPE_SYMTAB_POINTER (type). Consequently
the callback is called, marking the entry and everything reachable from it
live, including the index type. Unfortunately, the hash entry for the index
type is already gone.

During parsing of f3, a new index type equivalent to the old one is created,
but type_hash_canon cannot find the old index type in the hash table (since
that entry has been deleted), so the new index type is now a canonical type,
and gets an entry in the type_hash_table. Next, a new array type equivalent to
the old one is created, but type_hash_canon cannot find the old array type,
even though the entry has not been deleted. The new array type has a different
index type than the old array type, and consequently the hashcode for the new
array type is different than the hascode for the old array type, so the old
array type is not found. The new array type is now also a canonical type, and
gets an entry in the type_hash_table. The old index type, the old array type
and the hash table entry associated with the old array type are now unused but
not freed.

The question is whether to blame this on 
- invalid use of the garbage collection infrastructure. Using the if_marked
construction to mark an object live, is only allowed if everything reachable
from that object is also live. 
- the garbage collection infrastructure itself. If the if_marked construction
is used to mark an object live, the garbage collection infrastructure should
mark everything that is reachable from that object also as live.

The patch in comment 3 seems to take the first choice. I decided to explore the
second choice, and created a naive patch of ggc_mark_roots(). It solves the
inconsistent debug info problem, both for dwarf2 and for stabs. I did a debug
bootstrap build (-g3 -O0 -dH) with the patch and ran the testsuites (gcc, objc,
gfortran, g++, libgomp, libstdc++, libjava, libmudflap, libffi), with the same
results as a normal bootstrap build without the patch, so the patch looks sane
at least.

This is my first time looking into the gcc garbage collector, so I'd appreciate
some comments on my findings.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230

[Bug debug/31230] debug information depends on gc parameters

[tjvries at xs4all dot nl]

------- Comment #4 from tjvries at xs4all dot nl  2010-06-21 10:20 -------
Created an attachment (id=20953)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20953&action=view)
 minimal test case of 14 lines, cut down from varasm.i

I also ran into this bug, while building gcc 4.3.5 for x86_64-unknown-linux-gnu
with make {CFLAGS,BOOT_CFLAGS,STAGE1_CFLAGS}=\"-g3\ -O0\ -dH\".

I managed to minimized the test case down to 14 lines.

The difference in debug info can be reproduced using:
...
$ cc1 varasm.i -O0 -g -quiet -o varasm.s 
$ cc1 varasm.i -O0 -g -quiet -o varasm.s.0.0 --param ggc-min-expand=0 --param
ggc-min-heapsize=0 
...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230

[Bug debug/31230] debug information depends on gc parameters

[wilson at gcc dot gnu dot org]

------- Comment #3 from wilson at gcc dot gnu dot org  2007-03-30 22:49 -------
Created an attachment (id=13304)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13304&action=view)
Add equate_type_number_to_die call to prevent garbage collection.

This patch is untested, but works for the testcase in the bug report.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230

[Bug debug/31230] debug information depends on gc parameters

[wilson at gcc dot gnu dot org]

------- Comment #2 from wilson at gcc dot gnu dot org  2007-03-30 22:44 -------
I can reproduce the problem using the provided testcase.

It looks like all we have to do is mark the array type TYPE_DOMAIN as used, to
prevent it from being garbage collected.  This just requires adding an
equate_type_number_to_die call, which should be harmless by itself, I think. 
This  solves the problem for the provided testcase.  I haven't done a bootstrap
or gdb testsuite run to test the patch yet.

It might be nice to try to reuse this info, via lookup_type_die, now that we
have saved it.  Unfortunately, the dwarf3 standard doesn't have any provision
for this.  


-- 

wilson at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-30 22:44:06
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230

[Bug debug/31230] debug information depends on gc parameters

[jsm28 at gcc dot gnu dot org]

------- Comment #1 from jsm28 at gcc dot gnu dot org  2007-03-16 20:26 -------
Created an attachment (id=13215)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13215&action=view)
Testcase cut down from dbxout.i in original bootstrap failure.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230