-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
Comments
This looks familiar. I think there's a dup bug open already. |
Dup of #14319? |
Maybe, that isnt using |
I think BTW, it is probably fine with Go 1.9 even with |
|
I'm seeing this with go 1.8.3 on windows.
Edit: a |
Randy, this looks like a different problem. Please open a new issue
following the template provided
…On Sun, 9 Jul 2017, 12:13 Randy Fay ***@***.***> wrote:
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
...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#20935 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA1prUqwbVlk8xIBUlbvpMDNlC6J6ks5sMDdWgaJpZM4OQcyD>
.
|
Thanks - And as a note, I resolved mine with a |
Not a regression from Go1.8 so marking for Go1.10 |
@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:
|
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? |
What version of Go are you using (
go version
)?go 1.8.3
What operating system and processor architecture are you using (
go env
)?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?
The text was updated successfully, but these errors were encountered: