diff mbox

Recent Go patch broke Alpha bootstrap

Message ID CAKOQZ8xT_+tN4uoja-9jt2j_B-39g=zWHgcsXU4FgZJjGX9kcw@mail.gmail.com
State New
Headers show

Commit Message

Ian Lance Taylor Nov. 7, 2013, 11:39 p.m. UTC 
On Thu, Nov 7, 2013 at 2:25 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>
> Recent Go mega-patch broke Alpha bootstrap. Following fixlet is needed:
>
> --cut here--
> Index: runtime/proc.c
> ===================================================================
> --- runtime/proc.c      (revision 204522)
> +++ runtime/proc.c      (working copy)
> @@ -2098,7 +2098,7 @@
>                 __splitstack_block_signals_context(&newg->stack_context[0],
>                                                    &dont_block_signals, nil);
>  #else
> -               *ret_stack = runtime_mallocgc(stacksize,
> FlagNoProfiling|FlagNoGC, 0, 0);
> +               *ret_stack = runtime_mallocgc(stacksize, 0,
> FlagNoProfiling|FlagNoGC);
>                 *ret_stacksize = stacksize;
>                 newg->gcinitial_sp = *ret_stack;
>                 newg->gcstack_size = stacksize;
> --cut here--
>
> However, all runtime tests panic with:
>
> gmake[2]: *** [os/check] Error 1
> runtime: address space conflict: map(0xc000001000) = 0xc000002000
> fatal error: runtime: address space conflict

Thanks for the patch and report.  This patch should fix them.
Bootstrapped and tested on x86_64-unknown-linux-gnu, not that that
proves much.  Committed to mainline.

Ian

Comments

Uros Bizjak Nov. 8, 2013, 9:10 a.m. UTC | #1 
On Fri, Nov 8, 2013 at 12:39 AM, Ian Lance Taylor <iant@google.com> wrote:

>> Recent Go mega-patch broke Alpha bootstrap. Following fixlet is needed:
>>
> Thanks for the patch and report.  This patch should fix them.
> Bootstrapped and tested on x86_64-unknown-linux-gnu, not that that
> proves much.  Committed to mainline.

With your patch, I was able to compile libgo and run libgo testsuite.
There are two new testsuite failures for newly introduced tests:

--- FAIL: TestKillStartProcess (0.00 seconds)
        os_test.go:1173: Failed to build exe
/tmp/go-build420056795/main.exe: exec: "go": executable file not found
in $PATH
--- FAIL: TestKillFindProcess (0.00 seconds)
        os_test.go:1173: Failed to build exe
/tmp/go-build353151102/main.exe: exec: "go": executable file not found
in $PATH
FAIL
FAIL: os
gmake[2]: *** [os/check] Error 1

This should be trivial, I have no go in $PATH (IIRC, we already have
fixed failure like this).

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x1c]

goroutine 5 [running]:
syscall.Exitsyscall
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:1986
pprof.profileWriter
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/pprof.go:600
created by runtime_pprof.StartCPUProfile
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/pprof.go:594

goroutine 1 [chan receive]:
testing.RunTests
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:470
testing.Main
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:401
main.main
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/_testmain.go:34

goroutine 4 [chan receive]:
pprof_test.testCPUProfile
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/pprof_test.go:108
testing.tRunner
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:389
created by testing.RunTests
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:469
FAIL: runtime/pprof
gmake[2]: *** [runtime/pprof/check] Error 1

This one is new, I have to look into it a bit deeper.

All other libgo tests pass.

Uros.
Ian Lance Taylor Nov. 11, 2013, 7:52 p.m. UTC | #2 
On Fri, Nov 8, 2013 at 1:10 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal 0xb code=0x1 addr=0x1c]
>
> goroutine 5 [running]:
> syscall.Exitsyscall
>         ../../../gcc-svn/trunk/libgo/runtime/proc.c:1986
> pprof.profileWriter
>         /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/pprof.go:600
> created by runtime_pprof.StartCPUProfile
>         /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/pprof.go:594
>
> goroutine 1 [chan receive]:
> testing.RunTests
>         ../../../gcc-svn/trunk/libgo/go/testing/testing.go:470
> testing.Main
>         ../../../gcc-svn/trunk/libgo/go/testing/testing.go:401
> main.main
>         /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/_testmain.go:34
>
> goroutine 4 [chan receive]:
> pprof_test.testCPUProfile
>         /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest29851/test/pprof_test.go:108
> testing.tRunner
>         ../../../gcc-svn/trunk/libgo/go/testing/testing.go:389
> created by testing.RunTests
>         ../../../gcc-svn/trunk/libgo/go/testing/testing.go:469
> FAIL: runtime/pprof
> gmake[2]: *** [runtime/pprof/check] Error 1
>
> This one is new, I have to look into it a bit deeper.


I don't know what is happening here.  I can't recreate it.  There was
a different problem that could arise in runtime/pprof, that was fixed
by a patch I submitted on Saturday
(http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01016.html).  So it's
possible that this is fixed now.

If you are able to recreate it, try setting GOTRACEBACK=2 in the
environment.  That will provide more information in the backtrace.

Ian
Uros Bizjak Nov. 12, 2013, 7:52 a.m. UTC | #3 
On Mon, Nov 11, 2013 at 8:52 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Fri, Nov 8, 2013 at 1:10 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>
>> panic: runtime error: invalid memory address or nil pointer dereference
>> [signal 0xb code=0x1 addr=0x1c]

>> FAIL: runtime/pprof
>> gmake[2]: *** [runtime/pprof/check] Error 1
>>
>> This one is new, I have to look into it a bit deeper.
>
>
> I don't know what is happening here.  I can't recreate it.  There was
> a different problem that could arise in runtime/pprof, that was fixed
> by a patch I submitted on Saturday
> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01016.html).  So it's
> possible that this is fixed now.

The failure is specific to !USING_SPLIT_STACK targets:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x200009e9280 (LWP 21478)]
0x000000012001e854 in syscall.Exitsyscall () at
../../../gcc-svn/trunk/libgo/runtime/proc.c:1986
1986            m->p->syscalltick++;
(gdb) list
1981    #ifdef USING_SPLIT_STACK
1982            gp->gcstack = nil;
1983    #endif
1984            gp->gcnext_sp = nil;
1985            runtime_memclr(&gp->gcregs, sizeof gp->gcregs);
1986            m->p->syscalltick++;
1987    }
1988
1989    static bool
1990    exitsyscallfast(void)
(gdb) p m
$2 = <optimized out>

The crash is at line 1986, but it is unclear if m or p are null.

> If you are able to recreate it, try setting GOTRACEBACK=2 in the
> environment.  That will provide more information in the backtrace.

Following is full traceback:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x1c]

goroutine 10 [running]:
runtime_dopanic
        ../../../gcc-svn/trunk/libgo/runtime/panic.c:77
__go_panic
        ../../../gcc-svn/trunk/libgo/runtime/go-panic.c:113
runtime_panicstring
        ../../../gcc-svn/trunk/libgo/runtime/panic.c:134
sig_panic_info_handler
        ../../../gcc-svn/trunk/libgo/runtime/go-signal.c:291

        :0
syscall.Exitsyscall
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:1986
runtime_notetsleepg
        ../../../gcc-svn/trunk/libgo/runtime/lock_futex.c:190
getprofile
        ../../../gcc-svn/trunk/libgo/runtime/cpuprof.c:370
runtime.CPUProfile
        ../../../gcc-svn/trunk/libgo/runtime/cpuprof.c:446
pprof.profileWriter
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest21332/test/pprof.go:600
kickoff
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:229

        :0

        :0
created by runtime_pprof.StartCPUProfile
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest21332/test/pprof.go:594

goroutine 1 [chan receive]:
runtime_mcall
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:292
runtime_chanrecv
        ../../../gcc-svn/trunk/libgo/runtime/chan.c:378
testing.RunTests
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:470
testing.Main
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:401
main.main
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest21332/test/_testmain.go:34
runtime_main
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:560
kickoff
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:229

        :0

        :0

goroutine 2 [syscall]:
        goroutine in C code; stack unavailable
created by runtime_main
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:547

goroutine 8 [chan receive]:
runtime_mcall
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:292
runtime_chanrecv
        ../../../gcc-svn/trunk/libgo/runtime/chan.c:378
__go_receive_small
        ../../../gcc-svn/trunk/libgo/runtime/chan.c:503
runtime_pprof.StopCPUProfile
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest21332/test/pprof.go:621
__go_undefer
        ../../../gcc-svn/trunk/libgo/runtime/go-defer.c:52
runtime_pprof_test.TestCPUProfileWithFork
        /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest21332/test/pprof_test.go:181
testing.tRunner
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:389
kickoff
        ../../../gcc-svn/trunk/libgo/runtime/proc.c:229

        :0

        :0
created by testing.RunTests
        ../../../gcc-svn/trunk/libgo/go/testing/testing.go:469

Uros.
Uros Bizjak Nov. 13, 2013, 3:25 p.m. UTC | #4 
On Tue, Nov 12, 2013 at 8:52 AM, Uros Bizjak <ubizjak@gmail.com> wrote:

>>> panic: runtime error: invalid memory address or nil pointer dereference
>>> [signal 0xb code=0x1 addr=0x1c]
>
>>> FAIL: runtime/pprof
>>> gmake[2]: *** [runtime/pprof/check] Error 1
>>>
>>> This one is new, I have to look into it a bit deeper.
>>
>>
>> I don't know what is happening here.  I can't recreate it.  There was
>> a different problem that could arise in runtime/pprof, that was fixed
>> by a patch I submitted on Saturday
>> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01016.html).  So it's
>> possible that this is fixed now.
>
> The failure is specific to !USING_SPLIT_STACK targets:

The same error triggered on CentOS 5.10 x86_64 (another
!USING_SPLIT_STACK target) for 32bit lib (net, runtime). The panic:
string is the same, only addr=0x9f. There are also a couple of
segfaults (database/sql, net/http) and abort in sync/atomic.

Uros.
diff mbox

Patch

diff -r 9f650ddab115 libgo/runtime/mheap.c
--- a/libgo/runtime/mheap.c	Wed Nov 06 11:23:33 2013 -0800
+++ b/libgo/runtime/mheap.c	Thu Nov 07 15:34:54 2013 -0800
@@ -68,6 +68,7 @@ 
 void
 runtime_MHeap_MapSpans(MHeap *h)
 {
+	uintptr pagesize;
 	uintptr n;
 
 	// Map spans array, PageSize at a time.
@@ -76,6 +77,8 @@ 
 		n -= (uintptr)h->arena_start;
 	n = n / PageSize * sizeof(h->spans[0]);
 	n = ROUND(n, PageSize);
+	pagesize = getpagesize();
+	n = ROUND(n, pagesize);
 	if(h->spans_mapped >= n)
 		return;
 	runtime_SysMap((byte*)h->spans + h->spans_mapped, n - h->spans_mapped, &mstats.other_sys);
diff -r 9f650ddab115 libgo/runtime/proc.c
--- a/libgo/runtime/proc.c	Wed Nov 06 11:23:33 2013 -0800
+++ b/libgo/runtime/proc.c	Thu Nov 07 15:34:54 2013 -0800
@@ -2098,7 +2098,7 @@ 
 		__splitstack_block_signals_context(&newg->stack_context[0],
 						   &dont_block_signals, nil);
 #else
-		*ret_stack = runtime_mallocgc(stacksize, FlagNoProfiling|FlagNoGC, 0, 0);
+		*ret_stack = runtime_mallocgc(stacksize, 0, FlagNoProfiling|FlagNoGC);
 		*ret_stacksize = stacksize;
 		newg->gcinitial_sp = *ret_stack;
 		newg->gcstack_size = stacksize;