runtime: fatal error: unexpected signal during runtime execution (during compilation)

[titanous]

What version of Go are you using (go version)?

go version go1.5beta2 linux/amd64

What operating system and processor architecture are you using?

Linux flynn 3.19.0-22-generic #22~14.04.1-Ubuntu SMP Wed Jun 17 10:03:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

What did you do?

Ran the following go build command (via the tup build system):

CGO_ENABLED=0 go build -ldflags="-X github.com/flynn/flynn/pkg/version.commit=dev -X github.com/flynn/flynn/pkg/version.branch=dev -X github.com/flynn/flynn/pkg/version.tag=none -X github.com/flynn/flynn/pkg/version.dirty=false" -o bin/flynn-postgres-api -tags="" ./api

What did you expect to see?

The program compile successfully.

What did you see instead?

Rarely, this error occurs when compiling a package (the package does not appear to be consistently the same):

# github.com/flynn/flynn/Godeps/_workspace/src/github.com/wadey/cryptorand
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x0 pc=0x441d11]

runtime stack:
runtime.throw(0x85e100, 0x2a)
    /usr/local/go/src/runtime/panic.go:527 +0x96
runtime.sigpanic()
    /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a
runtime.cfuncname(0x8dbe08, 0xbcac5)
    /usr/local/go/src/runtime/symtab.go:269 +0x71
runtime.funcname(0x8dbe08, 0x0, 0x0)
    /usr/local/go/src/runtime/symtab.go:273 +0x2d
runtime.funcspdelta(0x8dbe08, 0x456781, 0x1)
    /usr/local/go/src/runtime/symtab.go:295 +0x5f
runtime.gentraceback(0x424470, 0xc820028708, 0x0, 0xc820000180, 0x0, 0x0, 0x7fffffff, 0x896968, 0x7ffe7dbbffc0, 0x0, ...)
    /usr/local/go/src/runtime/traceback.go:219 +0x47f
runtime.copystack(0xc820000180, 0x1000)
    /usr/local/go/src/runtime/stack1.go:616 +0x1a7
runtime.newstack()
    /usr/local/go/src/runtime/stack1.go:801 +0xb9b
runtime.morestack()
    /usr/local/go/src/runtime/asm_amd64.s:330 +0x82

goroutine 1 [copystack, locked to thread]:
runtime.init.2()
    /usr/local/go/src/runtime/mstats.go:146 fp=0xc820028710 sp=0xc820028708
runtime.init()
    /usr/local/go/src/runtime/zversion.go:9 +0x36e fp=0xc820028770 sp=0xc820028710
runtime.main()
    /usr/local/go/src/runtime/proc.go:63 +0x112 fp=0xc8200287c0 sp=0xc820028770
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc8200287c8 sp=0xc8200287c0

[bradfitz]

What is your go env? And how many CPUs?

Is CGO_ENABLED=0 required? Are the -ldflag -X required?

[titanous]

What is your go env?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/vagrant/go"
GORACE=""
GOROOT="/vagrant/util/_toolchain/go"
GOTOOLDIR="/vagrant/util/_toolchain/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

And how many CPUs?

It's a Virtualbox VM with 4 CPUs.

Is CGO_ENABLED=0 required?

For some of the programs being compiled, this was required in order to do cross-compilation properly on Go 1.4.

Are the -ldflag -X required?

For testing builds they are not required, but we use the same build flags for testing and release.

So far this hasn't been happening frequently enough for me to isolate anything. If there is no readily apparent explanation, I can provision some compute resources to run many builds and try to figure out the frequency.

[ianlancetaylor]

CC @randall77

The crash is happening when funcspdelta is trying to report an error:

print("invalid spdelta ", funcname(f), " ", hex(f.entry), " ", hex(targetpc), " ", hex(f.pcsp), " ", x, "\n")

The call to funcname in this print statement is crashing, most likely because findmoduledatap(f.entry) is returning nil.

funcspdelta is being called because the stack growth code is walking the stack adjusting stack frames.

Oddly, this seems to be happening very early in program execution. Unfortunately, I can't tell which program is running. As a first step, please add the -x option to your go build command, so we can see the command that fails. Please also set the environment variable GOTRACEBACK=crash. That should give us a core dump for the crashing program, which may help us analyze the problem.

[gopherbot]

CL https://golang.org/cl/12391 mentions this issue.

[rsc]

Dup of #11792.