runtime: stack split bug

[gopherbot]

by awalterschulze:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Run test vir GOMAXPROCS=16
2.
3.

What is the expected output?
test should pass

What do you see instead?
signal 11

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Fedora

Which revision are you using?  (hg identify)
weekly.2012-03-12

Please provide any additional information below.
Test passes, but gives signal 11 (segmentation fault) when GOMAXPROCS=16.
Sorry for all the code.
I believe the important part is when the map at the bottom ( q := map[string][]Data ) is
built, since commenting out one map entry results in the test passing.

Attachments:

1. sixteen_test.go (6602 bytes)

[alberts]

Comment 1:

We reduced this code out of a bigger test. I'll double check tomorrow that this still
produces the segfault we saw initially, because I can't reproduce it on a virtual server
I have here. It might depend on how many cores you have whether you see this segfault. I
think it's important to run it as a test instead of as a command on its own.
Also, here's more fun which looks like a signal handling bug.
Change sixteen_test.go -> sixteen.go and change the test function to func main().
Now do:
while true; do GOMAXPROCS=16 ./main ; done
Now randomly press Ctrl-C a few times. I see lots of segfaults (probably unrelated to
the original report), I'm guessing in the signal handling code.

[alberts]

Comment 2:

I reported a separate issue #3314 for the signal handler segfault. This bug still stands.

[alberts]

Comment 3:

Reproduced with weekly.2012-03-13 +8328e5baaf10 on a machine with lots of cores:
$ ulimit -c unlimited
$ GOMAXPROCS=16 ./sixteen.test
Segmentation fault (core dumped)
$ gdb ./sixteen.test core.4537
(gdb) thread apply all bt
Thread 3 (LWP 4538):
#0  runtime.futex () at go/src/pkg/runtime/sys_linux_amd64.s:238
#1  0x00000000004132f3 in runtime.futexsleep (addr=void, val=void, ns=void) at
go/src/pkg/runtime/thread_linux.c:62
#2  0x0000000000408132 in runtime.notetsleep (n=void, ns=void) at
go/src/pkg/runtime/lock_futex.c:146
#3  0x000000000040ca84 in runtime.MHeap_Scavenger () at go/src/pkg/runtime/mheap.c:363
#4  0x000000000040df90 in schedunlock () at go/src/pkg/runtime/proc.c:262
#5  0x0000000000000000 in ?? ()
Thread 2 (LWP 4537):
#0  runtime.futex () at go/src/pkg/runtime/sys_linux_amd64.s:238
#1  0x00000000004132f3 in runtime.futexsleep (addr=void, val=void, ns=void) at
go/src/pkg/runtime/thread_linux.c:62
#2  0x000000000040807b in runtime.notesleep (n=void) at
go/src/pkg/runtime/lock_futex.c:124
#3  0x000000000040e870 in nextgandunlock () at go/src/pkg/runtime/proc.c:616
#4  0x000000000040ef02 in schedule (gp=void) at go/src/pkg/runtime/proc.c:871
#5  0x0000000000417ad3 in runtime.mcall (fn=void) at go/src/pkg/runtime/asm_amd64.s:157
#6  0x000000f840037000 in ?? ()
#7  0x0000000000000000 in ?? ()
Thread 1 (LWP 4539):
#0  0x00000000004117fd in runtime.sighandler (sig=void, info=void, context=void,
gp=void) at go/src/pkg/runtime/signal_linux_amd64.c:82
#1  0x0000000000418024 in runtime.sigtramp () at go/src/pkg/runtime/sys_linux_amd64.s:176
#2  0x0000000000418037 in runtime.sigtramp () at go/src/pkg/runtime/sys_linux_amd64.s:182
#3  0x0000000000000000 in ?? ()

[dsymonds]

Comment 4:

Labels changed: added priority-go1, go1-must, packagebug, removed priority-triage.

Owner changed to @rsc.

Status changed to Accepted.

[rsc]

Comment 5:

Thank you very much for this report.  I was able to reproduce the failure using
sixteen_test.go unmodified.  It is a stack split bug: the function has a stack frame
that is just barely big enough to warrant allocating a bit more than the default size
stack segment, but the linker gets the logic wrong and does not trigger this.  The fix
is easy, but I want to write a more thorough test.  I will have this fixed tomorrow.

[rsc]

Comment 7:

This issue was closed by revision 9e5db8c.

Status changed to Fixed.