go: cmd/compile: panic: offset too large
What version of Go are you using (go version
)?
$ go version go version go1.19 darwin/amd64
Does this issue reproduce with the latest release?
Unsure.
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="/Users/x/gopath/bin" GOCACHE="/Users/x/Library/Caches/go-build" GOENV="/Users/x/Library/Application Support/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/x/gopath/pkg/mod" GONOPROXY="*.s.com,*.s-s.com" GONOSUMDB="*.s.com,*.s-s.com" GOOS="darwin" GOPATH="/Users/x/gopath" GOPRIVATE="*.s.com,*.s-s.com" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GOVCS="" GOVERSION="go1.19" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/dev/null" 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 x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2b/74fz3jhd4wz4vnbf4z7ywzww0000gp/T/go-build668550611=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
$ PROJ_TEST_LOG_STDERR=1 go test -v -vet all -failfast -run TestStashOutgoing 2>&1 | tee /tmp/logs.txt
# spideroak.com/proj/policy [spideroak.com/proj/policy.test]
panic: offset too large
goroutine 560 [running]:
cmd/compile/internal/liveness.(*argLiveness).emit(0xc001039800)
/usr/local/go/src/cmd/compile/internal/liveness/arg.go:310 +0x3aa
cmd/compile/internal/liveness.ArgLiveness(0xc001ec92c0, 0xc000c32540, 0x123e35c?)
/usr/local/go/src/cmd/compile/internal/liveness/arg.go:218 +0xab5
cmd/compile/internal/ssagen.genssa(0xc000c32540, 0xc00098dce0)
/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:6834 +0x117
cmd/compile/internal/ssagen.Compile(0xc001ec92c0, 0xc002712f90?)
/usr/local/go/src/cmd/compile/internal/ssagen/pgen.go:193 +0x26f
cmd/compile/internal/gc.compileFunctions.func4.1(0x0?)
/usr/local/go/src/cmd/compile/internal/gc/compile.go:153 +0x3a
cmd/compile/internal/gc.compileFunctions.func3.1()
/usr/local/go/src/cmd/compile/internal/gc/compile.go:140 +0x4d
created by cmd/compile/internal/gc.compileFunctions.func3
/usr/local/go/src/cmd/compile/internal/gc/compile.go:138 +0x78
FAIL spideroak.com/proj/policy [build failed]
I don’t have any sort of repro yet. I’ve built this project easily hundreds of times with Go 1.19 and this is the first time it’s happened. Of course, it hasn’t happened in the dozens of test runs since. I know it’s not much to work with, but it’s probably better to report ICEs than not, right?
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 20 (9 by maintainers)
Commits related to this issue
- cmd/compile: copy blank parameter node when substituting function type When a function type is copied (e.g. for substituting type parameters), we make copies of its parameter ir.Name nodes, so they a... — committed to TroutSoftware/go by cherrymui 2 years ago
- [release-branch.go1.18] cmd/compile: copy blank parameter node when substituting function type When a function type is copied (e.g. for substituting type parameters), we make copies of its parameter ... — committed to golang/go by cherrymui 2 years ago
- [release-branch.go1.19] cmd/compile: copy blank parameter node when substituting function type When a function type is copied (e.g. for substituting type parameters), we make copies of its parameter ... — committed to golang/go by cherrymui 2 years ago
- [release-branch.go1.19] cmd/compile: copy blank parameter node when substituting function type When a function type is copied (e.g. for substituting type parameters), we make copies of its parameter ... — committed to tailscale/go by cherrymui 2 years ago
CL https://golang.org/cl/443158 seems to fix the race. I’m not really familiar with that code so not sure how correct it is, though.
Apparently it has something to do with
_
parameters in generic(?) closures. In this code (from query.go)if I make the
_
parameters in both closures named, it doesn’t seem to fail. Either one of them being_
seems to trigger the race.Code is at https://www.ueber.net/who/mjl/tmp/bstore.gorace.tgz It is about 7k lines, so hardly a minimal reproducer… The test_*.go files were the tests. Seems like compiling them stresses the compiler more. With the compiler-with-race-detector a race is detected in just few runs for me.
I’ll upload the code in a moment.
Yeah, if I can reproduce this again I’ll certainly post more information.