From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14927 invoked by alias); 21 Jun 2010 10:32:18 -0000 Received: (qmail 14786 invoked by uid 48); 21 Jun 2010 10:32:05 -0000 Date: Mon, 21 Jun 2010 10:32:00 -0000 Message-ID: <20100621103205.14785.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/31230] debug information depends on gc parameters In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "tjvries at xs4all dot nl" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg02008.txt.bz2 ------- 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