SIGSEGV in runtime.gostartcallfn

[gopherbot]

by arnehormann:

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. http://play.golang.org/p/TBjBo7ntJO

What do you see instead?

Stacktrace at
http://pastebin.com/79L9TjYG

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

6g

Which operating system are you using?

OS x 10.8.4

Which version are you using?  (run 'go version')

go version devel +50c9f3544eed Tue Aug 06 21:49:03 2013 +1000 darwin/amd64

Please provide any additional information below.

I was playing around with the recent Go/Scala benchmark at
http://eng.42go.com/scala-vs-go-tcp-benchmark/
When I commented the runtime.GOMAXPROCS(4), started the server and then started the
client, I got "fatal error: checkdead: runnable g". I didn't get it every
time, but 3 out of 5 times. I tried to build a reproducer and changed more than just the
two invocations of GOMAXPROCS. Now its a SIGSEGV.

The code is really bad, but it probably still shouldn't crash the runtime this way.

[gopherbot]

Comment 1 by arnehormann:

Small correction: The SIGSEGV happend when I called it twice. It was still running in
another terminal.

[dvyukov]

Comment 2:

Filed separate issue https://golang.org/issue/6070 for the "fatal
error: checkdead: runnable g".
Let's track only SIGSEGV in this issue.

Labels changed: added go1.2, removed priority-triage, go1.2maybe.

[dvyukov]

Comment 3:

I am a bit lost how to reproduce SIGSEGV crash.
Please provide the exact source code and how to run it.

[gopherbot]

Comment 4 by arnehormann:

Try http://play.golang.org/p/c2x8bcb1Qa
Run it in a terminal and start it in another while it's still running.
Apparently I messed up the upload by using the source because I also ran the wrong
binary...

[dvyukov]

Comment 5:

Part of the problem is that you do not check errors and try to work with nonexistent
objects.

[dvyukov]

Comment 6:

Keith, please take a look, it's something with newstackcall:
SIGSEGV: segmentation violation
PC=0x41c947
runtime.gostartcallfn(0x7f57ab387df8, 0x20)
    src/pkg/runtime/stack.c:354 +0x27
runtime.newstack()
    src/pkg/runtime/stack.c:338 +0x540
runtime: unexpected return pc for runtime.newstackcall called from 0xc210010000
runtime.newstackcall(0x4a1f64, 0x3)
    src/pkg/runtime/asm_amd64.s:271 +0x68
goroutine 5 [stack split]:
runtime.newstackcall(0x20, 0xc21004c038)
    src/pkg/runtime/asm_amd64.s:235 fp=0x7f57aec43e70
runtime.panic(0x4dd720, 0xc21000a270)
    src/pkg/runtime/panic.c:236 +0x71 fp=0x7f57aec43eb0
runtime.panicstring(0x5e9cc8)
    src/pkg/runtime/panic.c:512 +0xa5 fp=0x7f57aec43ef0
runtime.sigpanic()
    src/pkg/runtime/os_linux.c:233 +0x16a fp=0x7f57aec43f08
main.func·001(0x0, 0x0)
    /tmp/test.go:20 +0xa4 fp=0x7f57aec43f90
runtime.goexit()
    src/pkg/runtime/proc.c:1332 fp=0x7f57aec43f98
created by main.server
    /tmp/test.go:31 +0xaa

Owner changed to @randall77.

Status changed to Accepted.

[randall77]

Comment 7:

Well there's certainly a bug in the example code, conn is sometimes nil, so
conn.Read(buf[0:]) panics.  During the panic, it stack splits.  Then the gostartcallfn
segvs trying to restart the panic.  That shouldn't happen, I'll keep looking at that.

[randall77]

Comment 8:

Ok, here's what is going on.  the "defer conn.Close()" call makes a bogus FuncVal* that
gets passed to runtime.deferproc (it points to address 0x20).  Nothing is wrong with the
rest of the code, gostartcallfn is just trying to start the deferred routine and segvs
when trying to read from the FuncVal*.
The address 0x20 comes from &((Itab*)nil).fun.  Looks like calling defer on a method of
a nil interface value barfs.  I'll see if I can't make a simple example.

[randall77]

Comment 9:

Here's a simple example:
package main
type Closer interface {
    Close()
}
func main() {
     var x Closer
     defer x.Close()
}
when you run it, it panics inside runtime.jmpdefer when it tries to dereference the bad
FuncVal.

[dvyukov]

Comment 10:

Note that it's "fine" to defer nil func call, it must not cause "runtime: unexpected
return pc for runtime.newstackcall called from 0xc210010000" and must be recoverable.
E.g. the following strange program must run fine. While currently it says:
runtime: unknown argument frame size for runtime.jmpdefer called from 0x20d3 [main.main]
fatal error: invalid stack
package main
import "fmt"
import "runtime"
func main() {
    defer func() {
        var buf [1<<20]byte
        fmt.Print(string(buf[:runtime.Stack(buf[:], true)]))
        recover()
    }()
    var fn func()
    defer fn()
    fmt.Println("Hello, playground")
}

[randall77]

Comment 11:

jmpdefer needed its arg size specified so it can unwind correctly when it segvs.  CL
12536045 out for review.

Status changed to Started.

[randall77]

Comment 12:

This issue was closed by revision a97a91d.

Status changed to Fixed.