From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 980 invoked by alias); 14 Aug 2009 09:41:18 -0000 Received: (qmail 929 invoked by uid 22791); 14 Aug 2009 09:41:17 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Aug 2009 09:41:09 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7E9f5Dn014423; Fri, 14 Aug 2009 05:41:05 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7E9f3JU010261; Fri, 14 Aug 2009 05:41:03 -0400 Received: from zebedee.pink (vpn1-4-90.ams2.redhat.com [10.36.4.90]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n7E9f1id012595; Fri, 14 Aug 2009 05:41:02 -0400 Message-ID: <4A85312D.1070609@redhat.com> Date: Fri, 14 Aug 2009 14:05:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.17 (X11/20081009) MIME-Version: 1.0 To: okellogg@freenet.de CC: gcc@gcc.gnu.org Subject: Re: Trace crash in gargabe collector to the code at fault? References: <400e1c6303a9c2d634341fa3e69ce5ae@email.freenet.de> In-Reply-To: <400e1c6303a9c2d634341fa3e69ce5ae@email.freenet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00235.txt.bz2 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.