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/link: nosplit stack overflow error when cross compiling in Go 1.5.1 #12764

Closed
samherrmann opened this issue Sep 26, 2015 · 10 comments

Comments

Projects
None yet
7 participants
@samherrmann
Copy link

commented Sep 26, 2015

I was trying to cross compile my Go project on windows/amd64 for linux/386, but got a "nosplit stack overflow" error. I followed the instructions that are outlined here. With GOOS=linux and GOARCH=386, my go env looks as follows:

set GOARCH=386
set GOBIN=
set GOEXE=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=linux
set GOPATH=C:\dev\gopath
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GO15VENDOREXPERIMENT=0
set CC=gcc
set GOGCCFLAGS=-fPIC -m32 -fmessage-length=0
set CXX=g++
set CGO_ENABLED=0

The code I tried to compile is a simple hello world

package main

import (
    "fmt"
)

func main() {
    fmt.Println("hello go")
}

The complete error I got when running go build is:

runtime.cgocall: nosplit stack overflow
508     assumed on entry to runtime.cgocall (nosplit)
464     after runtime.cgocall (nosplit) uses 44
460     on entry to runtime.exitsyscall (nosplit)
272     after runtime.exitsyscall (nosplit) uses 188
268     on entry to runtime.exitsyscallfast (nosplit)
108     after runtime.exitsyscallfast (nosplit) uses 160
104     on entry to runtime.writebarrierptr (nosplit)
64      after runtime.writebarrierptr (nosplit) uses 40
60      on entry to runtime.writebarrierptr_nostore1 (nosplit)
8       after runtime.writebarrierptr_nostore1 (nosplit) uses 52
4       on entry to runtime.acquirem (nosplit)
-12     after runtime.acquirem (nosplit) uses 16 runtime.cgocallbackg: nosplit stack overflow
508     assumed on entry to runtime.cgocallbackg (nosplit)
460     after runtime.cgocallbackg (nosplit) uses 48
456     on entry to runtime.exitsyscall (nosplit)
268     after runtime.exitsyscall (nosplit) uses 188
264     on entry to runtime.exitsyscallfast (nosplit)
104     after runtime.exitsyscallfast (nosplit) uses 160
100     on entry to runtime.writebarrierptr (nosplit)
60      after runtime.writebarrierptr (nosplit) uses 40
56      on entry to runtime.writebarrierptr_nostore1 (nosplit)
4       after runtime.writebarrierptr_nostore1 (nosplit) uses 52
0       on entry to runtime.acquirem (nosplit)
-16     after runtime.acquirem (nosplit) uses 16 runtime.cgocallback_gofunc: nosplit stack overflow
508     assumed on entry to runtime.cgocallback_gofunc (nosplit)
496     after runtime.cgocallback_gofunc (nosplit) uses 12
492     on entry to runtime.cgocallbackg (nosplit)
444     after runtime.cgocallbackg (nosplit) uses 48
440     on entry to runtime.exitsyscall (nosplit)
252     after runtime.exitsyscall (nosplit) uses 188
248     on entry to runtime.exitsyscallfast (nosplit)
88      after runtime.exitsyscallfast (nosplit) uses 160
84      on entry to runtime.writebarrierptr (nosplit)
44      after runtime.writebarrierptr (nosplit) uses 40
40      on entry to runtime.writebarrierptr_nostore1 (nosplit)
-12     after runtime.writebarrierptr_nostore1 (nosplit) uses 52

Other target configurations that did work are GOOS=windows GOARCH=386 and GOOS=linux GOARCH=amd64, but GOOS=linux GOARCH=386 does not work.

@rakyll rakyll changed the title nosplit stack overflow error when cross compiling in Go 1.5.1 cmd/link: nosplit stack overflow error when cross compiling in Go 1.5.1 Sep 26, 2015

@rakyll rakyll added this to the Go1.6 milestone Sep 26, 2015

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Nov 5, 2015

I cannot reproduce this with go1.5.1:

C:\dev\src\t>go version
go version go1.5.1 windows/amd64

C:\dev\src\t>go env
set GOARCH=386
set GOBIN=
set GOEXE=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=linux
set GOPATH=c:\dev
set GORACE=
set GOROOT=c:\dev\go
set GOTOOLDIR=c:\dev\go\pkg\tool\windows_amd64
set GO15VENDOREXPERIMENT=
set CC=gcc
set GOGCCFLAGS=-fPIC -m32 -fmessage-length=0
set CXX=g++
set CGO_ENABLED=0

C:\dev\src\t>type main.go
package main

import (
    "fmt"
)

func main() {
    fmt.Println("hello go")
}
C:\dev\src\t>go build

C:\dev\src\t>

I can successfully build the exe. I can even run it on linux.

Reopen if you can provide more steps to try. Thank you.

Alex

@samherrmann

This comment has been minimized.

Copy link
Author

commented Nov 26, 2015

@alexbrainman I re-ran the experiment on two machines and kept everything exactly the same as you have documented. Here are my findings:

  • Windows 8.1 Pro (i5) -> build is successful and I can run the executable on Linux.
  • Windows 10 Home (i7) -> build fails with the error in my original post.
@alexbrainman

This comment has been minimized.

Copy link
Member

commented Nov 26, 2015

I don't know. I don't have Windows 10 computers. Perhaps this bug is tickled by that.

Alex

@alexbrainman alexbrainman reopened this Nov 26, 2015

@samherrmann

This comment has been minimized.

Copy link
Author

commented Nov 27, 2015

I'm still working on isolating the issue. I was NOT able to reproduce the issue on Windows 10 Pro (i5) running in VirtualBox.

@samherrmann

This comment has been minimized.

Copy link
Author

commented Nov 27, 2015

I'm closing this issue after all. How the issue went away for me is a mystery to me, but for the record here is what I did on my machine following successful tests on other machines:

1.) Reinstall Go for Windows amd64
Test Result: build failed
2.) Uninstall Go and use ZIP version for Windows amd64
Test Result: build passed
3.) Reinstall Go for Windows amd64
Test Result: build passed

@rrh

This comment has been minimized.

Copy link

commented Nov 30, 2015

Please reopen this issue.

I see a similar issue when cross compiling to GOOS=linux on macosx using go 1.5.1 It happens in the link step, AFAICT from using the -v option to go build.

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2015

The reflect.typelinks issue is fixed on tip by https://golang.org/cl/16932.

@rrh: are you compiling with -N? The stack sizes you are reporting are too large. The values I see are

cgocallbackg 88
exitsyscall 32
exitsyscallfast 88
writebarrierptr 40
writebarrierptr_nostore1 48

@rrh

This comment has been minimized.

Copy link

commented Nov 30, 2015

I was using the -N flag. If I don't use it, the problem goes away.

@ipavlo

This comment has been minimized.

Copy link

commented Dec 3, 2015

I'm getting the same error on Windows 10(i7).
If go1.5.1.windows-amd64 from zip used - build succesfully passed, but resulting exe with simple "Hello world" stucking and not running.
If use "-a" flag or remove windows_amd64 folder from "go\pkg" folder - build with "-N -l" failed. Without "-N" passed but resulting exe stucks and not running.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2015

@Agnikay In general it doesn't help much to comment on a closed issue. Few people will see your comment. In this case, see #13431 .

@golang golang locked and limited conversation to collaborators Dec 14, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.