cmd/compile: compiling with Go 1.5.1 breaks after doing "go build -i -gcflags '-N -l' -a" (nosplit stack overflow)

[shawnburke]

If I do go build -i -gcflags "-N -l" -a, I get stuck into this state with the following stack. -a alone or -gcflags "-N -l" is fine. But this combo gets me into this state so even go build will fail going forward...some binary is getting rebuilt in a bad way, can't figure out which one.

I'm building this project: https://github.com/uber/tchannel-go/tree/master/thrift/thrift-gen.

If I brew uninstall, brew install, then go build, it's fine until I run the above command again.

shawn:[ thrift-gen ]> go build
# thrift-gen
runtime.cgocallbackg: nosplit stack overflow
    504 assumed on entry to runtime.cgocallbackg (nosplit)
    416 after runtime.cgocallbackg (nosplit) uses 88
    408 on entry to runtime.exitsyscall (nosplit)
    288 after runtime.exitsyscall (nosplit) uses 120
    280 on entry to runtime.exitsyscallfast (nosplit)
    120 after runtime.exitsyscallfast (nosplit) uses 160
    112 on entry to runtime.writebarrierptr (nosplit)
    64  after runtime.writebarrierptr (nosplit) uses 48
    56  on entry to runtime.writebarrierptr_nostore1 (nosplit)
    0   after runtime.writebarrierptr_nostore1 (nosplit) uses 56
    -8  on entry to runtime.acquirem (nosplit)
reflect.typelinks: nosplit stack overflow
    504 assumed on entry to reflect.typelinks (nosplit)
    352 after reflect.typelinks (nosplit) uses 152
    344 on entry to runtime.typedmemmove (nosplit)
    320 after runtime.typedmemmove (nosplit) uses 24
    312 on entry to runtime.heapBitsBulkBarrier (nosplit)
    192 after runtime.heapBitsBulkBarrier (nosplit) uses 120
    184 on entry to runtime.throw (nosplit)
    160 after runtime.throw (nosplit) uses 24
    152 on entry to runtime.dopanic (nosplit)
    72  after runtime.dopanic (nosplit) uses 80
    64  on entry to runtime.getcallerpc (nosplit)
    56  after runtime.getcallerpc (nosplit) uses 8
    48  on entry to runtime.nextBarrierPC (nosplit)
    8   after runtime.nextBarrierPC (nosplit) uses 40
    0   on entry to runtime.panicindex
    -8  on entry to runtime.morestack (nosplit)
runtime.cgocallback_gofunc: nosplit stack overflow
    504 assumed on entry to runtime.cgocallback_gofunc (nosplit)
    496 after runtime.cgocallback_gofunc (nosplit) uses 8
    488 on entry to runtime.cgocallbackg (nosplit)
    400 after runtime.cgocallbackg (nosplit) uses 88
    392 on entry to runtime.exitsyscall (nosplit)
    272 after runtime.exitsyscall (nosplit) uses 120
    264 on entry to runtime.exitsyscallfast (nosplit)
    104 after runtime.exitsyscallfast (nosplit) uses 160
    96  on entry to runtime.writebarrierptr (nosplit)
    48  after runtime.writebarrierptr (nosplit) uses 48
    40  on entry to runtime.writebarrierptr_nostore1 (nosplit)
    -16 after runtime.writebarrierptr_nostore1 (nosplit) uses 56

I tried setting CGO_ENABLED=0, no change.

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/shawn/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.5.1/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.5.1/libexec/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT=""
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

[davecheney]

Does it break without -N ?

On Sun, Nov 22, 2015 at 9:20 AM, Shawn Burke notifications@github.com
wrote:

If I do go build -i -gcflags "-N -l" -a, I get stuck into this state with
the following stack. -a alone or -gcflags "-N -l" is fine. But this combo
gets me into this state so even go build will fail going forward...some
binary is getting rebuilt in a bad way, can't figure out which one.

If I brew uninstall, brew install, then go build, it's fine until I run
the above command again.

shawn:[ thrift-gen ]> go build

thrift-gen

runtime.cgocallbackg: nosplit stack overflow
504 assumed on entry to runtime.cgocallbackg (nosplit)
416 after runtime.cgocallbackg (nosplit) uses 88
408 on entry to runtime.exitsyscall (nosplit)
288 after runtime.exitsyscall (nosplit) uses 120
280 on entry to runtime.exitsyscallfast (nosplit)
120 after runtime.exitsyscallfast (nosplit) uses 160
112 on entry to runtime.writebarrierptr (nosplit)
64 after runtime.writebarrierptr (nosplit) uses 48
56 on entry to runtime.writebarrierptr_nostore1 (nosplit)
0 after runtime.writebarrierptr_nostore1 (nosplit) uses 56
-8 on entry to runtime.acquirem (nosplit)
reflect.typelinks: nosplit stack overflow
504 assumed on entry to reflect.typelinks (nosplit)
352 after reflect.typelinks (nosplit) uses 152
344 on entry to runtime.typedmemmove (nosplit)
320 after runtime.typedmemmove (nosplit) uses 24
312 on entry to runtime.heapBitsBulkBarrier (nosplit)
192 after runtime.heapBitsBulkBarrier (nosplit) uses 120
184 on entry to runtime.throw (nosplit)
160 after runtime.throw (nosplit) uses 24
152 on entry to runtime.dopanic (nosplit)
72 after runtime.dopanic (nosplit) uses 80
64 on entry to runtime.getcallerpc (nosplit)
56 after runtime.getcallerpc (nosplit) uses 8
48 on entry to runtime.nextBarrierPC (nosplit)
8 after runtime.nextBarrierPC (nosplit) uses 40
0 on entry to runtime.panicindex
-8 on entry to runtime.morestack (nosplit)
runtime.cgocallback_gofunc: nosplit stack overflow
504 assumed on entry to runtime.cgocallback_gofunc (nosplit)
496 after runtime.cgocallback_gofunc (nosplit) uses 8
488 on entry to runtime.cgocallbackg (nosplit)
400 after runtime.cgocallbackg (nosplit) uses 88
392 on entry to runtime.exitsyscall (nosplit)
272 after runtime.exitsyscall (nosplit) uses 120
264 on entry to runtime.exitsyscallfast (nosplit)
104 after runtime.exitsyscallfast (nosplit) uses 160
96 on entry to runtime.writebarrierptr (nosplit)
48 after runtime.writebarrierptr (nosplit) uses 48
40 on entry to runtime.writebarrierptr_nostore1 (nosplit)
-16 after runtime.writebarrierptr_nostore1 (nosplit) uses 56

I tried setting CGO_ENABLED=0, no change.

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/shawn/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.5.1/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.5.1/libexec/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT=""
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

—
Reply to this email directly or view it on GitHub
#13354.

[shawnburke]

Good question - nope, it does not so that appears to be key.

[rsc]

I can reproduce this using Go 1.5. A quicker fix is to run go build -i -a. In general, go build -i -a rebuilds and installs all dependencies of the current package, whether or not they need it. When you add -gcflags '-N -l' it rebuilds everything, including the standard library, and installs one that is no longer linkable into any actual program. That's bad, of course, but it doesn't break the go command, so rerunning the command without the -gcflags puts everything back.

I cannot reproduce this using the current dev branch, likely because we raised the stack limits again.

There's a real problem here but likely not high enough priority for Go 1.6, given both the easy workaround and the fact that it's not happening anymore.

[bradfitz]

I believe that the massive set of cmd/go caching changes for Go 1.10 by @rsc fix this issue.

[bradfitz]

Actually, unsure. Because I just filed related #22797 which started failing at the content-based caching change.