From owner-svn-src-all@FreeBSD.ORG Sat Mar 28 18:26:13 2015 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E25366D; Sat, 28 Mar 2015 18:26:13 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0104E3B0; Sat, 28 Mar 2015 18:26:12 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2SIPi6d081565; Sat, 28 Mar 2015 10:25:48 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503281825.t2SIPi6d081565@gw.catspoiler.org> Date: Sat, 28 Mar 2015 11:25:44 -0700 (PDT) From: Don Lewis Subject: Re: svn commit: r280327 - in head/sys: kern vm To: alc@rice.edu In-Reply-To: <5516EB31.7000309@rice.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: src-committers@FreeBSD.org, alc@FreeBSD.org, svn-src-all@FreeBSD.org, bdrewery@FreeBSD.org, portmgr@FreeBSD.org, svn-src-head@FreeBSD.org, clusteradm@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 18:26:13 -0000 On 28 Mar, Alan Cox wrote: > On 03/28/2015 12:29, Bryan Drewery wrote: >> On 3/27/2015 9:41 PM, Don Lewis wrote: >>> I was not seeing this problem on my older package builder running >>> 10.1-STABLE. Since this problem has not shown up on the FreeBSD package >>> building cluster, I got suspicious that the change was quite recent. >>> >>> This old gcc bug report: >>> led me to suspect >>> mmap(). >>> >>> The old gcc source file /usr/src/contrib/gcc/ggc-common.c does a couple >>> of mmap() calls. Tne first is in mmap_gt_pch_get_address() where a >>> NULL first argument is used. The address that gets returned is stashed >>> away and the region is unmapped. Then a later call in >>> mmap_gt_pch_use_address() passes this saved address to mmap() as a >>> hint. It expects the mapped region to get mapped to the same base >>> address. If this does not happen, the above error is the result. >> I don't know what I'm talking about but that doesn't sound like a very >> safe assumption for the gcc code to make. > > > Your intuition is correct. It is not. And, in fact, under Solaris and > Linux, gcc does not make this assumption. > > I suspect that the solution used by gcc under Solaris would work for > us. However, that would entail modifying gcc in older branches. That's somewhat problematic because we use releases + official updates for package building. To continue doing this, we'd have to treat the gcc fix as an EN.