From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4802 invoked by alias); 1 Nov 2011 05:21:05 -0000 Received: (qmail 4788 invoked by uid 22791); 1 Nov 2011 05:21:02 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,T_TVD_MIME_NO_HEADERS X-Spam-Check-By: sourceware.org Received: from mail-gy0-f175.google.com (HELO mail-gy0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Nov 2011 05:20:48 +0000 Received: by gyd8 with SMTP id 8so2802337gyd.20 for ; Mon, 31 Oct 2011 22:20:48 -0700 (PDT) Received: by 10.68.72.33 with SMTP id a1mr28758498pbv.44.1320124847578; Mon, 31 Oct 2011 22:20:47 -0700 (PDT) Received: by 10.68.72.33 with SMTP id a1mr28758471pbv.44.1320124847368; Mon, 31 Oct 2011 22:20:47 -0700 (PDT) Received: from coign.google.com ([216.239.45.130]) by mx.google.com with ESMTPS id km16sm36763777pbb.9.2011.10.31.22.20.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 22:20:46 -0700 (PDT) From: Ian Lance Taylor To: Rainer Orth Cc: gcc-patches@gcc.gnu.org, gofrontend-dev@googlegroups.com Subject: Re: Go patch committed: Update Go library References: Date: Tue, 01 Nov 2011 05:21:00 -0000 In-Reply-To: (Rainer Orth's message of "Mon, 31 Oct 2011 17:14:58 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00010.txt.bz2 --=-=-= Content-length: 1504 Rainer Orth writes: > After this change, I'm seeing another issue: most 32-bit go execution > tests fail like this on Solaris 11/x86: > > /vol/gcc/src/hg/trunk/local/libgo/runtime/malloc.goc:366: libgo assertion failure > FAIL: go.go-torture/execute/array-1.go execution, -O0 > > Running the test under truss, I find: > > 14261: mmap(0xFF000000, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0) Err#12 ENOMEM > > With truss -u (user function tracing), I see: > > 14285/1@1: -> libgo:runtime_mallocinit() > 14285/1@1: -> libgo:runtime_InitSizes() > 14285/1@1: <- libgo:runtime_InitSizes() = 2 > 14285/1@1: -> libgo:runtime_SysReserve() > 14285/1: mmap(0xFF000000, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0) Err#12 ENOMEM > 14285/1@1: <- libgo:runtime_SysReserve() = -1 > 14285/1@1: -> libgo:__go_assert_fail() > > If I remove the adjustment in runtime/malloc.goc (runtime_mallocinit), > the test passes: > > 14445/1: mmap(0xFEF78114, 805306368, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xCE000000 > > This stuff seems incredibly fragile, and I don't exactly understand > why. I don't understand why one case passes and the other fails. In an attempt to make this work better, I committed the appended patch. It will at least avoid asking for impossible situations, such as the one in this example. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu (including the 32-bit tests, which I always run anyhow). Committed to mainline. Ian --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=foo.patch Content-Description: patch Content-length: 571 diff -r 250b34075533 libgo/runtime/malloc.goc --- a/libgo/runtime/malloc.goc Mon Oct 31 21:54:06 2011 -0700 +++ b/libgo/runtime/malloc.goc Mon Oct 31 22:18:21 2011 -0700 @@ -358,6 +358,8 @@ // away from the running binary image and then round up // to a MB boundary. want = (byte*)(((uintptr)end + (1<<18) + (1<<20) - 1)&~((1<<20)-1)); + if(0xffffffff - (uintptr)want <= bitmap_size + arena_size) + want = 0; p = runtime_SysReserve(want, bitmap_size + arena_size); if(p == nil) runtime_throw("runtime: cannot reserve arena virtual address space"); --=-=-=--