From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6739 invoked by alias); 21 Aug 2013 01:26: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 6730 invoked by uid 89); 21 Aug 2013 01:26:11 -0000 X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,PLING_QUERY,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 21 Aug 2013 01:26:10 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7L1Q9eZ015671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 21:26:09 -0400 Received: from [10.3.234.23] (vpn-234-23.phx2.redhat.com [10.3.234.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7L1Q7sK016913; Tue, 20 Aug 2013 21:26:07 -0400 Message-ID: <1377048362.8019.19.camel@surprise> Subject: Re: Recent libstdc++-v3 regressions (PCHs related?!?) From: David Malcolm To: Paolo Carlini Cc: "'gcc@gcc.gnu.org'" , Jan Hubicka Date: Wed, 21 Aug 2013 09:58:00 -0000 In-Reply-To: <5213850F.2000604@oracle.com> References: <52135B14.6030707@oracle.com> <1377009699.23910.11.camel@surprise> <5213850F.2000604@oracle.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00221.txt.bz2 On Tue, 2013-08-20 at 17:02 +0200, Paolo Carlini wrote: > Hi, > > On 08/20/2013 04:41 PM, David Malcolm wrote: > > On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote: > >> Hi, > >> > >> sorry it the issue is by now well known but... I see many libstdc++-v3 > >> regressions on at least x86_64-linux. When running the libstdc++-v3 > >> testsuite (which uses PCHs) one gets tons of new fails like the below. > >> That's annoying, a lot of confusing noise. > >> > >> Thanks! > >> Paolo. > >> > >> PS: CC-ing two "random" ;) people lately very active. > > Sorry about this - looking at the backtrace this could well be due to > > me, specifically r201865, which moved the gcc::pass_manager and all the > > passes into the GC heap (so that we can then move GC-owned per-pass > > state into the pass instances). > I can confirm that r201864 isn't affected. Thanks for looking into this! Thanks. It tool me a while to reproduce the failure - perhaps on my test box, GC is happening much less than on yours? On a test run I only saw 6 failures due to this (my test machine appears to have 3.6 GB of RAM) Is there a good way to encourage the testsuite to GC more? (I know about setting --param ggc-min-expand=0 --param ggc-min-heapsize=0 on an individual invocation, but is there a standard way of doing this? Or do I need to run the whole thing in a cgroup or somesuch, and constrain the available RAM?) The bug (or, at least the first one I see) is that the pass_manager's "passes_by_id" array is being allocated using XRESIZEVEC (xrealloc, hence malloc/realloc under the covers), but given that all this is meant to interact with GC, it needs to be persistable to PCH [1]. Now that I see it, I'm wondering how it managed to work in my prior testing. Presumably the array always happened to be allocated at the same location between the process that created the pch file and the processes that read it. Is there a good way to perturb memory so that accidentally mixing a malloc allocation with a GC allocation is more reliably fatal, to shake out this kind of bug? i.e. to make malloc place its results at locations that vary from process to process? (perhaps in libiberty?) Perhaps also valgrind can catch this kind of thing? Thanks Dave [1] I wish I could just have GC and not have to deal with PCH; oh well.