Rainer Orth <[email protected]> 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
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");
