From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65478 invoked by alias); 19 Aug 2019 23:05:12 -0000 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 Received: (qmail 65465 invoked by uid 89); 19 Aug 2019 23:05:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:a26bed2, H*i:sk:a26bed2, HTo:D*marvell.com X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 23:05:10 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B958D30860CA; Mon, 19 Aug 2019 23:05:09 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-5.rdu2.redhat.com [10.10.112.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id D71F718FC2; Mon, 19 Aug 2019 23:05:08 +0000 (UTC) Subject: Re: Help with bug in GCC garbage collector To: Steve Ellcey , "gcc@gcc.gnu.org" References: From: Jeff Law Openpgp: preference=signencrypt Message-ID: <5bd227e3-af73-145e-9bd6-88560e6509a4@redhat.com> Date: Mon, 19 Aug 2019 23:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00146.txt.bz2 On 8/19/19 4:59 PM, Steve Ellcey wrote: > I was wondering if anyone could help me investigate a bug I am > seeing in the GCC garbage collector. This bug (which may or may not > be PR 89179) is causing a segfault in GCC, but when I try to create > a preprocessed source file, the bug doesn't trigger. The problem is > with the garbage collector trying to mark some memory that has > already been freed. I have tracked down the initial allocation to: > > symbol_table::allocate_cgraph_symbol > > It has: > > node = ggc_cleared_alloc (); > > to allocate a cgraph node. With the GGC debugging on I see this > allocated: > > Allocating object, requested size=360, actual=360 at 0xffff7029c210 > on 0x41b148c0 > > then freed: > > Freeing object, actual size=360, at 0xffff7029c210 on 0x41b148c0 > > And then later, while the garbage collector is marking nodes, I see: > > Marking 0xffff7029c210 > > The garbage collector shouldn't be marking this node if has already > been freed. > > So I guess my main question is how do I figure out how the garbage > collector got to this memory location? I am guessing some GTY > pointer is still pointing to it and hadn't got nulled out when the > memory was freed. Does that seem like the most likely cause? > > I am not sure why I am only running into this with one particular > application on my Aarch64 platform. I am building it with -fopenmp, > which could have something to do with it (though there are no simd > functions in the application). The application is not that large as > C++ programs go. There's a real good chance Martin Liska has already fixed this. He's made a couple fixes in the last week or so with the interactions between the GC system and the symbol tables. 2019-08-15 Martin Liska PR ipa/91404 * passes.c (order): Remove. (uid_hash_t): Likewise). (remove_cgraph_node_from_order): Remove from set of pointers (cgraph_node *). (insert_cgraph_node_to_order): New. (duplicate_cgraph_node_to_order): New. (do_per_function_toporder): Register all 3 cgraph hooks. Skip removed_nodes now as we know about all of them. The way I'd approach would be to configure a compiler with --enable-checking=gc,gcac, just build it through stage1. Then run your test through that compiler which should fail. THen apply Martin's patch (or update to the head of the trunk), rebuild the stage1 compiler and verify it works. jeff