--- 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=20954action=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
