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

runtime, cmd/compile: nosplit stack overflow with -pkgdir and -gcflags -N #20935

Closed
vektah opened this issue Jul 7, 2017 · 11 comments
Closed

Comments

@vektah
Copy link

vektah commented Jul 7, 2017

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

go 1.8.3

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

$ uname -a
Linux roci 4.11.7-1-ARCH #1 SMP PREEMPT Sat Jun 24 09:07:09 CEST 2017 x86_64 GNU/Linux

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/adam/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build708844366=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
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 get github.com/vektah/ior
cd $GOPATH/src/github.com/vektah/ior
go build -pkgdir .pkg -i -v -gcflags="-N -l"

What did you expect to see?

A binary with optimization disabled for use with delve exec, using incremental compilation for quick rebuilds.

What did you see instead?

root@bc9b0dccde45:/go/src/github.com/vektah/ior# go build -pkgdir .pkg -i -v -gcflags="-N -l"
github.com/vektah/ior

# github.com/vektah/ior
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.morestack: nosplit stack overflow
        744     assumed on entry to runtime.sigprofNonGo (nosplit)
        656     after runtime.sigprofNonGo (nosplit) uses 88
        648     on entry to runtime.(*cpuProfile).addNonGo (nosplit)
        600     after runtime.(*cpuProfile).addNonGo (nosplit) uses 48
        592     on entry to runtime.(*cpuProfile).addWithFlushlog (nosplit)
        224     after runtime.(*cpuProfile).addWithFlushlog (nosplit) uses 368
        216     on entry to runtime.(*cpuProfile).evict (nosplit)
        8       after runtime.(*cpuProfile).evict (nosplit) uses 208
        0       on entry to function pointer
        -8      on entry to runtime.morestack (nosplit)
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
@bradfitz
Copy link
Contributor

bradfitz commented Jul 7, 2017

This looks familiar. I think there's a dup bug open already.

@bradfitz
Copy link
Contributor

bradfitz commented Jul 7, 2017

Dup of #14319?

@vektah
Copy link
Author

vektah commented Jul 7, 2017

Maybe, that isnt using -pkgdir though and if I drop either -pkgdir or -N everything works fine. It seems to be the combination of both.

@cherrymui
Copy link
Member

Maybe, that isnt using -pkgdir though and if I drop either -pkgdir or -N everything works fine. It seems to be the combination of both.

I think -pkgdir triggers a rebuild for standard library packages, because, well, in the specified pkgdir they do not exist. Especially, rebuilding the runtime with -N blows up, which is known and so we increase the stack guard when running make.bash/all.bash with -N.

BTW, it is probably fine with Go 1.9 even with -pkgdir and -gcflags -N, as now -N is no-op for building runtime.

@cherrymui
Copy link
Member

$ go build -v hello.go
command-line-arguments
$ go build -v -pkgdir . hello.go
runtime/internal/sys
runtime/internal/atomic
runtime
command-line-arguments
$ go build -v -pkgdir . -gcflags -N hello.go ### go tip
runtime/internal/sys
runtime/internal/atomic
runtime
command-line-arguments
$ go1.8 build -v -pkgdir . -gcflags -N hello.go ### go 1.8
runtime/internal/sys
runtime/internal/atomic
runtime
command-line-arguments
# command-line-arguments
runtime.nextBarrierPC: nosplit stack overflow
	744	assumed on entry to runtime.cgocall (nosplit)
	648	after runtime.cgocall (nosplit) uses 96
	640	on entry to runtime.entersyscall (nosplit)
	576	after runtime.entersyscall (nosplit) uses 64
	568	on entry to runtime.reentersyscall (nosplit)
	376	after runtime.reentersyscall (nosplit) uses 192
	368	on entry to runtime.casgstatus (nosplit)
	200	after runtime.casgstatus (nosplit) uses 168
	192	on entry to runtime.throw (nosplit)
	160	after runtime.throw (nosplit) uses 32
	152	on entry to runtime.dopanic (nosplit)
	32	after runtime.dopanic (nosplit) uses 120
	24	on entry to runtime.getcallerpc (nosplit)
	8	after runtime.getcallerpc (nosplit) uses 16
	0	on entry to runtime.nextBarrierPC (nosplit)
	-16	after runtime.nextBarrierPC (nosplit) uses 16
runtime.nextBarrierPC: nosplit stack overflow
...

@rfay
Copy link

rfay commented Jul 9, 2017

I'm seeing this with go 1.8.3 on windows.

go build -i -o C:\Users\randy\AppData\Local\Temp\Unnamedgo C:\Users\randy\go\src\github.com\drud\ddev\cmd\ddev\main.go
# 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
...

Edit: a go build -a resolved this situation after much gnashing of teeth.

@davecheney
Copy link
Contributor

davecheney commented Jul 9, 2017 via email

@rfay
Copy link

rfay commented Jul 9, 2017

Thanks - And as a note, I resolved mine with a go build -a - apparently corrupted cache of some type. Thanks for the response @davecheney

@odeke-em odeke-em changed the title nosplit stack overflow with -pkgdir and -gcflags -N runtime, cmd/compile: nosplit stack overflow with -pkgdir and -gcflags -N Jul 21, 2017
@odeke-em
Copy link
Member

Not a regression from Go1.8 so marking for Go1.10

@odeke-em odeke-em added this to the Go1.10 milestone Jul 21, 2017
@cherrymui
Copy link
Member

@odeke-em, this is no longer a problem for Go 1.9. For Go 1.8, I think this is known and there isn't much we can do. The workaround is to build runtime first without -N:

go install -pkgdir .pkg runtime
go build -pkgdir .pkg -i -v -gcflags=-N <target>

@cherrymui cherrymui removed this from the Go1.10 milestone Jul 21, 2017
@odeke-em
Copy link
Member

Thank you @cherrymui for the update. In that case, since we've got a workaround and this no longer a problem for Go1.9, should be closing this bug?

@rsc rsc closed this as completed Nov 2, 2017
@golang golang locked and limited conversation to collaborators Nov 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants