cmd/compile: nosplit stack overflow with gcflags "-N -l"

[spikecurtis]

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

 % go version
go version go1.18.4 darwin/arm64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE=""

GOARCH="arm64"

GOBIN=""

GOCACHE="/Users/spike/Library/Caches/go-build"

GOENV="/Users/spike/Library/Application Support/go/env"

GOEXE=""

GOEXPERIMENT=""

GOFLAGS=""

GOHOSTARCH="arm64"

GOHOSTOS="darwin"

GOINSECURE=""

GOMODCACHE="/Users/spike/go/pkg/mod"

GONOPROXY=""

GONOSUMDB=""

GOOS="darwin"

GOPATH="/Users/spike/go"

GOPRIVATE=""

GOPROXY="https://proxy.golang.org,direct"

GOROOT="/opt/homebrew/Cellar/go/1.18.4/libexec"

GOSUMDB="sum.golang.org"

GOTMPDIR=""

GOTOOLDIR="/opt/homebrew/Cellar/go/1.18.4/libexec/pkg/tool/darwin_arm64"

GOVCS=""

GOVERSION="go1.18.4"

GCCGO="gccgo"

AR="ar"

CC="clang"

CXX="clang++"

CGO_ENABLED="1"

GOMOD="/Users/spike/repos/coder/go.mod"

GOWORK=""

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

PKG_CONFIG="pkg-config"

GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/53/zffdtv3x7lg_pyhrk85p7_nw0000gn/T/go-build856354956=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I'm working with https://github.com/coder/coder and attempting a debug build in Goland. Goland calls something like

go test  -gcflags all="-N -l" github.com/coder/coder/coderd/devtunnel 

this combination of flags is presumably an attempt to keep breakpoints from being skipped, allow directly stepping through the code, etc.

What did you expect to see?

Successful build & run of test

What did you see instead?

% go test  -gcflags all="-N -l" github.com/coder/coder/coderd/devtunnel 
# github.com/coder/coder/coderd/devtunnel.test
runtime.spanOf: nosplit stack overflow
	792	assumed on entry to gvisor.dev/gvisor/pkg/refs.(*AtomicRefCount).DecRef<1> (nosplit)
	744	after gvisor.dev/gvisor/pkg/refs.(*AtomicRefCount).DecRef<1> (nosplit) uses 48
	600	after gvisor.dev/gvisor/pkg/refs.(*AtomicRefCount).DecRefWithDestructor<1> (nosplit) uses 144
	472	after gvisor.dev/gvisor/pkg/refs.(*weakRefList).Remove<1> (nosplit) uses 128
	456	after gvisor.dev/gvisor/pkg/refs.(*weakRefEntry).SetNext<1> (nosplit) uses 16
	232	after runtime.gcWriteBarrier<1> (nosplit) uses 224
	200	after runtime.wbBufFlush<0> (nosplit) uses 32
	168	after runtime.wbBufFlush<1> (nosplit) uses 32
	120	after runtime.cgoCheckWriteBarrier<1> (nosplit) uses 48
	40	after runtime.cgoIsGoPointer<1> (nosplit) uses 80
	8	after runtime.inHeapOrStack<1> (nosplit) uses 32
	-40	after runtime.spanOf<1> (nosplit) uses 48
FAIL	github.com/coder/coder/coderd/devtunnel [build failed]
FAIL

Notes

#14319 is similar but claims this was fixed long ago, and I'm seeing on latest release.

Interestingly, I can't reproduce it on Ubuntu, but it always happens on macOS for me.

[randall77]

This is a problem with gvisor.dev/gvisor, not with Go. The code in https://github.com/google/gvisor/blob/551d65b4e5e9/pkg/refs/refcounter.go uses go:nosplit in places where it could cause nosplit overflow when compiling with -N.
Generally go:nosplit is not intended for use outside the stdlib (for precisely this reason - it can lead to nosplit chains that are too long).

[spikecurtis]

Thanks! I'll chase them