Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
shawnburke opened this issue Nov 21, 2015 · 6 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone

Comments

@shawnburke
Copy link

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
Copy link
Contributor

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
Copy link
Author

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

@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Nov 23, 2015
@ianlancetaylor ianlancetaylor changed the title Compiling with Go 1.5.1 breaks after doing "go build -i -gcflags '-N -l' -a" (nosplit stack overflow) cmd/compile: compiling with Go 1.5.1 breaks after doing "go build -i -gcflags '-N -l' -a" (nosplit stack overflow) Nov 23, 2015
@rsc
Copy link
Contributor

rsc commented Dec 17, 2015

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.

@rsc rsc modified the milestones: Unplanned, Go1.6 Dec 17, 2015
@bradfitz
Copy link
Contributor

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

@bradfitz
Copy link
Contributor

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

@bradfitz bradfitz reopened this Nov 18, 2017
@bradfitz bradfitz modified the milestones: Unplanned, Go1.10 Nov 18, 2017
@bradfitz bradfitz added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 18, 2017
@cherrymui
Copy link
Member

This is not reproducible now. The runtime is always built with optimization enabled, and so no more stack overflow.

@golang golang locked and limited conversation to collaborators Nov 22, 2018
@rsc rsc removed their assignment Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Development

No branches or pull requests

7 participants