After updating to latest on master branch, strange one time compilation failure.

[mrjrieke]

Yesterday, just after updating to the latest tip (but before recompiling the go executable I think), I received a strange one time error. I normally wouldn't file what appears to be a bug (because I could no longer reproduce after recompiling go) but for the oddness of the error.

Are there known issues where if the GOROOT (source) does not match identically with the compiled go executable, you can get strange errors like this?

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

go tip -- sometime on 1/9/2016

What operating system and processor architecture are you using (go env)?

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/go"
GORACE=""
GOROOT="/go"
GOTOOLDIR="/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/yq/v1t_9k3s7f57_4x3x1008mnc0000gn/T/go-build158070598=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

/go build -o -gcflags "-N -l" /main.go

What did you expect to see?

Compilation success.

What did you see instead?

command-line-arguments

runtime.(*mspan).base: nosplit stack overflow
744 assumed on entry to runtime.cgoCheckMemmove (nosplit)
696 after runtime.cgoCheckMemmove (nosplit) uses 48
688 on entry to runtime.cgoCheckTypedBlock (nosplit)
376 after runtime.cgoCheckTypedBlock (nosplit) uses 312
368 on entry to runtime.cgoCheckBits (nosplit)
224 after runtime.cgoCheckBits (nosplit) uses 144
216 on entry to runtime.cgoIsGoPointer (nosplit)
64 after runtime.cgoIsGoPointer (nosplit) uses 152
56 on entry to runtime.inHeapOrStack (nosplit)
0 after runtime.inHeapOrStack (nosplit) uses 56
-8 on entry to runtime.(*mspan).base
runtime.inHeapOrStack: nosplit stack overflow
744 assumed on entry to runtime.cgoCheckSliceCopy (nosplit)
672 after runtime.cgoCheckSliceCopy (nosplit) uses 72
664 on entry to runtime.cgoCheckTypedBlock (nosplit)
352 after runtime.cgoCheckTypedBlock (nosplit) uses 312
344 on entry to runtime.cgoCheckBits (nosplit)
200 after runtime.cgoCheckBits (nosplit) uses 144
192 on entry to runtime.cgoIsGoPointer (nosplit)
40 after runtime.cgoIsGoPointer (nosplit) uses 152
32 on entry to runtime.inHeapOrStack (nosplit)
-24 after runtime.inHeapOrStack (nosplit) uses 56
runtime.inHeapOrStack: nosplit stack overflow
744 assumed on entry to runtime.typedmemmove (nosplit)
696 after runtime.typedmemmove (nosplit) uses 48
688 on entry to runtime.cgoCheckMemmove (nosplit)
640 after runtime.cgoCheckMemmove (nosplit) uses 48
632 on entry to runtime.cgoCheckTypedBlock (nosplit)
320 after runtime.cgoCheckTypedBlock (nosplit) uses 312
312 on entry to runtime.cgoCheckBits (nosplit)
168 after runtime.cgoCheckBits (nosplit) uses 144
160 on entry to runtime.cgoIsGoPointer (nosplit)
8 after runtime.cgoIsGoPointer (nosplit) uses 152
0 on entry to runtime.inHeapOrStack (nosplit)
-56 after runtime.inHeapOrStack (nosplit) uses 56
runtime.cgoIsGoPointer: nosplit stack overflow
744 assumed on entry to runtime.typedslicecopy (nosplit)
600 after runtime.typedslicecopy (nosplit) uses 144
592 on entry to runtime.cgoCheckSliceCopy (nosplit)
520 after runtime.cgoCheckSliceCopy (nosplit) uses 72
512 on entry to runtime.cgoCheckTypedBlock (nosplit)
200 after runtime.cgoCheckTypedBlock (nosplit) uses 312
192 on entry to runtime.cgoCheckBits (nosplit)
48 after runtime.cgoCheckBits (nosplit) uses 144
40 on entry to runtime.cgoIsGoPointer (nosplit)
-112 after runtime.cgoIsGoPointer (nosplit) uses 152
runtime.dopanic: nosplit stack overflow
744 assumed on entry to runtime.freedefer (nosplit)
528 after runtime.freedefer (nosplit) uses 216
520 on entry to runtime.typedmemmove (nosplit)
472 after runtime.typedmemmove (nosplit) uses 48
464 on entry to runtime.bulkBarrierPreWrite (nosplit)
104 after runtime.bulkBarrierPreWrite (nosplit) uses 360
96 on entry to runtime.throw (nosplit)
64 after runtime.throw (nosplit) uses 32
56 on entry to runtime.dopanic (nosplit)
-32 after runtime.dopanic (nosplit) uses 88
runtime.bulkBarrierPreWrite: nosplit stack overflow
744 assumed on entry to runtime.deferreturn (nosplit)
640 after runtime.deferreturn (nosplit) uses 104
632 on entry to runtime.freedefer (nosplit)
416 after runtime.freedefer (nosplit) uses 216
408 on entry to runtime.typedmemmove (nosplit)
360 after runtime.typedmemmove (nosplit) uses 48
352 on entry to runtime.bulkBarrierPreWrite (nosplit)
-8 after runtime.bulkBarrierPreWrite (nosplit) uses 360
runtime.(*cpuProfile).evict: nosplit stack overflow
744 assumed on entry to runtime.sigprofNonGoPC (nosplit)
632 after runtime.sigprofNonGoPC (nosplit) uses 112
624 on entry to runtime.(*cpuProfile).addNonGo (nosplit)
576 after runtime.(*cpuProfile).addNonGo (nosplit) uses 48
568 on entry to runtime.(*cpuProfile).addWithFlushlog (nosplit)
200 after runtime.(*cpuProfile).addWithFlushlog (nosplit) uses 368
192 on entry to runtime.(*cpuProfile).evict (nosplit)
-16 after runtime.(*cpuProfile).evict (nosplit) uses 208
runtime.(*cpuProfile).addWithFlushlog: nosplit stack overflow
744 assumed on entry to runtime.sigtrampgo (nosplit)
488 after runtime.sigtrampgo (nosplit) uses 256
480 on entry to runtime.sigprofNonGoPC (nosplit)
368 after runtime.sigprofNonGoPC (nosplit) uses 112
360 on entry to runtime.(*cpuProfile).addNonGo (nosplit)
312 after runtime.(*cpuProfile).addNonGo (nosplit) uses 48
304 on entry to runtime.(*cpuProfile).addWithFlushlog (nosplit)
-64 after runtime.(*cpuProfile).addWithFlushlog (nosplit) uses 368

[josharian]

Thanks for taking the time to file a bug.

Are there known issues where if the GOROOT (source) does not match identically with the compiled go executable, you can get strange errors like this?

Yep. :) All sorts of things can go awry if the toolchain doesn't match the stdlib.