cmd/compile: panic: offset too large #55357

elagergren-spideroak · 2022-09-22T23:08:58Z

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?

The text was updated successfully, but these errors were encountered:

cherrymui · 2022-09-22T23:12:15Z

I've built this project easily hundreds of times with Go 1.19 and this is the first time it's happened.

Were they building the same source code, or different? That is, is this a nondeterministic failure, or an ICE because the input source code is changed? Thanks.

elagergren-spideroak · 2022-09-22T23:21:12Z

@cherrymui sorry, usually different source code.

I've lost my scrollback buffer, so I can't say for certain, I believe this compiler panic occurred after making an edit to the source code. But, I did re-run that same source code after the compiler panic occurred and it did (and has not) not panicked.

cherrymui · 2022-09-22T23:30:07Z

Thanks. So it sounds like nondeterministic failure. Maybe next time if you can have some input that can trigger the failure (even nondeterministically), that would be helpful.

For that particular panic, I think we only add to lv.args for offset < 0xff https://cs.opensource.google/go/go/+/master:src/cmd/compile/internal/liveness/arg.go;l=106, so it shouldn't happen. Maybe memory corruption or data race?

elagergren-spideroak · 2022-09-22T23:32:06Z

Yeah, if I can reproduce this again I'll certainly post more information.

mjl- · 2022-10-13T18:04:20Z

I've been seeing the same issue a few times during the last few days, but with go1.19.2 on linux/amd64.

go build
go vet
staticcheck
go test -shuffle=on -coverprofile cover.out
# github.com/mjl-/bstore [github.com/mjl-/bstore.test]
panic: offset too large

goroutine 1473 [running]:
cmd/compile/internal/liveness.(*argLiveness).emit(0xc00540f800)
	/usr/local/go/src/cmd/compile/internal/liveness/arg.go:310 +0x3aa
cmd/compile/internal/liveness.ArgLiveness(0xc003893a40, 0xc005712700, 0xc000370690?)
	/usr/local/go/src/cmd/compile/internal/liveness/arg.go:218 +0xab5
cmd/compile/internal/ssagen.genssa(0xc005712700, 0xc0023f4e00)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:6909 +0x117
cmd/compile/internal/ssagen.Compile(0xc003893a40, 0xc0052c4f90?)
	/usr/local/go/src/cmd/compile/internal/ssagen/pgen.go:197 +0x26f
cmd/compile/internal/gc.compileFunctions.func4.1(0xc000e0e030?)
	/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	github.com/mjl-/bstore [build failed]

$ go version
go version go1.19.2 linux/amd64

$ uname -a
Linux x1 5.18.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10) x86_64 GNU/Linux

(This code isn't online yet.) It doesn't do anything special. It does use generics, unlike most Go code I compile much more often without getting this random panic. If it happens again, I'll try a go clean and a rebuild. For me too the next build after this panic (without changing any source files) succeeds as normal.

I'm assuming it is OK to see paths pointing to /usr/local even though I don't have any Go toolchain/source there. I keep my go toolchains in $HOME/sdk and that's where I can find the files with linenumbers from the stacktrace.

mjl- · 2022-10-14T13:06:24Z

I have been able to reproduce this on multiple two more machines with the same code and go1.19.2. Faster machines seem to get to the problem with fewer attempts. My laptop triggers it typically within 200 runs. My macbook pro 2016 darwin/amd64 gets there within 200 runs as well, I got it once over 420 runs on a slower linux/amd64 cloud vm with 2 processors. I have not been able to trigger this on an older linux/386 cloud vm with 1 processor after about 500 runs. On my laptop it didn't yet trigger after 520 runs with GOMAXPROCS=1, and also not after 700 runs with GO19CONCURRENTCOMPILATION=0 (a flag I've seen before, I don't know if this makes sense for this kind of error). My laptops /proc/cpuinfo lists 8 processors of Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz.

I have been getting these errors while running "go test", but I've change the _test.go files to regular .go files and just "go build" triggers the same error. I could send the code somewhere.

cherrymui · 2022-10-14T14:26:18Z

@mjl- thanks for the update. It would be great if you could post a reproducer. It is fine if it only fails with 200 runs, or even 2000 runs. I guess there is some sort of race, which is only triggered with some specific input source code.

Would you mind also try to see if it fails if you build the compiler with the race detector? That is, go install -race cmd/compile then go build (or go test) your program. (After that you may want to go install cmd/compile to restore the normal compiler, so it doesn't slow down all compilations.) Thanks.

mjl- · 2022-10-14T15:18:49Z

# github.com/mjl-/bstore
==================
WARNING: DATA RACE
Read at 0x00c001eaa100 by goroutine 679:
  cmd/compile/internal/ir.(*Name).FrameOffset()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ir/name.go:203 +0x1ff7
  cmd/compile/internal/liveness.ArgLiveness()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/liveness/arg.go:106 +0x2004
  cmd/compile/internal/ssagen.genssa()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/ssa.go:6909 +0x2da
  cmd/compile/internal/ssagen.Compile()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/pgen.go:197 +0x4c6
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:153 +0x53
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b

Previous write at 0x00c001eaa100 by goroutine 683:
  cmd/compile/internal/ir.(*Name).SetFrameOffset()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ir/name.go:204 +0x21b
  cmd/compile/internal/abi.(*ABIConfig).updateOffset()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/abi/abiutils.go:458 +0x1d2
  cmd/compile/internal/abi.(*ABIConfig).ABIAnalyze()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/abi/abiutils.go:441 +0x364
  cmd/compile/internal/ssagen.buildssa()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/ssa.go:458 +0x29fc
  cmd/compile/internal/ssagen.Compile()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/pgen.go:187 +0x5a
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:153 +0x53
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b

Goroutine 679 (running) created at:
  cmd/compile/internal/gc.compileFunctions.func3()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:138 +0xd6
  cmd/compile/internal/gc.compileFunctions.func4()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:152 +0x63
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:154 +0xbb
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b

Goroutine 683 (running) created at:
  cmd/compile/internal/gc.compileFunctions.func3()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:138 +0xd6
  cmd/compile/internal/gc.compileFunctions.func4()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:152 +0x63
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:154 +0xbb
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b
==================
==================
WARNING: DATA RACE
Read at 0x00c001eaa0ec by goroutine 679:
  cmd/compile/internal/ir.(*Name).Addrtaken()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ir/name.go:249 +0x44
  cmd/compile/internal/liveness.ArgLiveness.func1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/liveness/arg.go:119 +0x18
  cmd/compile/internal/liveness.ArgLiveness()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/liveness/arg.go:123 +0x3c5
  cmd/compile/internal/ssagen.genssa()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/ssa.go:6909 +0x2da
  cmd/compile/internal/ssagen.Compile()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/pgen.go:197 +0x4c6
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:153 +0x53
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b

Previous write at 0x00c001eaa0ec by goroutine 683:
  cmd/compile/internal/ir.(*bitset16).set()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ir/bitset.go:35 +0x284
  cmd/compile/internal/ir.(*Name).SetIsOutputParamInRegisters()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ir/name.go:261 +0x259
  cmd/compile/internal/abi.(*ABIConfig).updateOffset()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/abi/abiutils.go:459 +0x22a
  cmd/compile/internal/abi.(*ABIConfig).ABIAnalyze()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/abi/abiutils.go:441 +0x364
  cmd/compile/internal/ssagen.buildssa()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/ssa.go:458 +0x29fc
  cmd/compile/internal/ssagen.Compile()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/ssagen/pgen.go:187 +0x5a
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:153 +0x53
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b

Goroutine 679 (running) created at:
  cmd/compile/internal/gc.compileFunctions.func3()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:138 +0xd6
  cmd/compile/internal/gc.compileFunctions.func4()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:152 +0x63
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:154 +0xbb
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b

Goroutine 683 (running) created at:
  cmd/compile/internal/gc.compileFunctions.func3()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:138 +0xd6
  cmd/compile/internal/gc.compileFunctions.func4()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:152 +0x63
  cmd/compile/internal/gc.compileFunctions.func4.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:154 +0xbb
  cmd/compile/internal/gc.compileFunctions.func3.1()
      /home/mjl/sdk/go1.19.2/src/cmd/compile/internal/gc/compile.go:140 +0x5b
==================
Found 2 data race(s)

I'll upload the code in a moment.

cherrymui · 2022-10-14T15:29:52Z

Thanks! It looks to me like that two functions shared a single ir.(*Name), perhaps for a parameter? (Maybe one of them is a wrapper or some compiler-generated function?) This seems wrong.

mjl- · 2022-10-14T15:41:41Z

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.

cuonglm · 2022-10-14T17:36:50Z

@mjl- to be clear, how could we reproduce this? I mean running go test or anything else?

I couldn't reproduce in my Linux.

mjl- · 2022-10-14T18:06:25Z

I've been running this:

(set -e; i=1; while true; do echo run $i; let i++; time $HOME/go/bin/go1.19.2 build; echo >>empty.go; done)

The echo is a simple way to get the new compilation.

cherrymui · 2022-10-14T21:01:47Z

Thanks for the reproducer. With race-detector-enabled compiler I can reproduce pretty consistently (5/5) with Go 1.19, but I cannot reproduce at Go tip with 100 runs. Go tip with GOEXPERIMENT=nounified also reproduces, although with a lower rate.

My guess is that for some compiler-generated function (possibly wrapper?), the non-unified-IR frontend (incorrectly) generated a shared ir.Name node, whereas unified IR doesn't have this problem.

I'll see whether we can make a fix for the old backend and backport.

cherrymui · 2022-10-14T22:25:16Z

Apparently it has something to do with _ parameters in generic(?) closures. In this code (from query.go)

// Count returns the number of selected records.
func (q *Query[T]) Count() (n int, rerr error) {
        defer q.finish(&rerr)
        q.checkNotNext()

        err := q.foreachKey(false, false, func(kb []byte, _ T) error {
                n++
                return nil
        })
        return n, err
}

// List returns all selected records.
func (q *Query[T]) List() (list []T, rerr error) {
        defer q.finish(&rerr)
        q.checkNotNext()

        var l []T
        err := q.foreachKey(false, true, func(_ []byte, v T) error {
                l = append(l, v)
                return nil
        })
        if err != nil {
                return nil, err
        }
        return l, nil
}

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.

cherrymui · 2022-10-15T00:01:25Z

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.

gopherbot · 2022-10-15T00:01:42Z

Change https://go.dev/cl/443158 mentions this issue: cmd/compile: copy blank parameter node when substituting function type

cherrymui · 2022-10-20T22:26:24Z

@gopherbot please backport this to previous releases. This can cause build failure for valid code. Thanks.

gopherbot · 2022-10-20T22:26:32Z

Backport issue(s) opened: #56359 (for 1.18), #56360 (for 1.19).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

gopherbot · 2022-10-24T19:47:06Z

Change https://go.dev/cl/445176 mentions this issue: [release-branch.go1.19] cmd/compile: copy blank parameter node when substituting function type

gopherbot · 2022-10-24T19:49:10Z

Change https://go.dev/cl/445177 mentions this issue: [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 ir.Name nodes, so they are not shared with the old function type. But currently a blank (_) identifier is not copied but shared. The parameter node's frame offset is assigned (in ABI analysis) and then used in the concurrent backend. Shared node can cause a data race. Make a new blank parameter node to avoid sharing. (Unified IR does already not have this problem. This fixes non-unified-IR mode.) This seems to fix golang#55357. Change-Id: Ie27f08e5589ac7d5d3f0d0d5de1a21e4fd2765c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/443158 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>

…ubstituting 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 are not shared with the old function type. But currently a blank (_) identifier is not copied but shared. The parameter node's frame offset is assigned (in ABI analysis) and then used in the concurrent backend. Shared node can cause a data race. Make a new blank parameter node to avoid sharing. (Unified IR does already not have this problem. This fixes non-unified-IR mode.) Updates #55357. Fixes #56359. Change-Id: Ie27f08e5589ac7d5d3f0d0d5de1a21e4fd2765c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/443158 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> (cherry picked from commit 4725c71) Reviewed-on: https://go-review.googlesource.com/c/go/+/445177

…ubstituting 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 are not shared with the old function type. But currently a blank (_) identifier is not copied but shared. The parameter node's frame offset is assigned (in ABI analysis) and then used in the concurrent backend. Shared node can cause a data race. Make a new blank parameter node to avoid sharing. (Unified IR does already not have this problem. This fixes non-unified-IR mode.) Updates #55357. Fixes #56360. Change-Id: Ie27f08e5589ac7d5d3f0d0d5de1a21e4fd2765c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/443158 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> (cherry picked from commit 4725c71) Reviewed-on: https://go-review.googlesource.com/c/go/+/445176

…ubstituting 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 are not shared with the old function type. But currently a blank (_) identifier is not copied but shared. The parameter node's frame offset is assigned (in ABI analysis) and then used in the concurrent backend. Shared node can cause a data race. Make a new blank parameter node to avoid sharing. (Unified IR does already not have this problem. This fixes non-unified-IR mode.) Updates golang#55357. Fixes golang#56360. Change-Id: Ie27f08e5589ac7d5d3f0d0d5de1a21e4fd2765c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/443158 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> (cherry picked from commit 4725c71) Reviewed-on: https://go-review.googlesource.com/c/go/+/445176

gopherbot added the compiler/runtime label Sep 22, 2022

cherrymui added the NeedsInvestigation label Sep 22, 2022

cherrymui added the WaitingForInfo label Sep 22, 2022

mknyszek added this to Go Compiler / Runtime Sep 28, 2022

cherrymui removed the WaitingForInfo label Oct 14, 2022

cherrymui self-assigned this Oct 14, 2022

mknyszek added this to the Go1.20 milestone Oct 19, 2022

mknyszek moved this to In Progress in Go Compiler / Runtime Oct 19, 2022

gopherbot closed this as completed in 4725c71 Oct 20, 2022

Repository owner moved this from In Progress to Done in Go Compiler / Runtime Oct 20, 2022

This was referenced Oct 20, 2022

cmd/compile: panic: offset too large [1.18 backport] #56359

Closed

cmd/compile: panic: offset too large [1.19 backport] #56360

Closed

mknyszek removed this from Go Compiler / Runtime Apr 19, 2023

golang locked and limited conversation to collaborators Oct 24, 2023

gopherbot added the FrozenDueToAge label Oct 24, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/compile: panic: offset too large #55357

cmd/compile: panic: offset too large #55357

elagergren-spideroak commented Sep 22, 2022

cherrymui commented Sep 22, 2022

elagergren-spideroak commented Sep 22, 2022 •

edited

Loading

cherrymui commented Sep 22, 2022

elagergren-spideroak commented Sep 22, 2022

mjl- commented Oct 13, 2022

mjl- commented Oct 14, 2022

cherrymui commented Oct 14, 2022

mjl- commented Oct 14, 2022

cherrymui commented Oct 14, 2022

mjl- commented Oct 14, 2022 •

edited

Loading

cuonglm commented Oct 14, 2022 •

edited

Loading

mjl- commented Oct 14, 2022

cherrymui commented Oct 14, 2022 •

edited

Loading

cherrymui commented Oct 14, 2022

cherrymui commented Oct 15, 2022

gopherbot commented Oct 15, 2022

cherrymui commented Oct 20, 2022

gopherbot commented Oct 20, 2022

gopherbot commented Oct 24, 2022

gopherbot commented Oct 24, 2022

cmd/compile: panic: offset too large #55357

cmd/compile: panic: offset too large #55357

Comments

elagergren-spideroak commented Sep 22, 2022

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

Does this issue reproduce with the latest release?

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

What did you do?

cherrymui commented Sep 22, 2022

elagergren-spideroak commented Sep 22, 2022 • edited Loading

cherrymui commented Sep 22, 2022

elagergren-spideroak commented Sep 22, 2022

mjl- commented Oct 13, 2022

mjl- commented Oct 14, 2022

cherrymui commented Oct 14, 2022

mjl- commented Oct 14, 2022

cherrymui commented Oct 14, 2022

mjl- commented Oct 14, 2022 • edited Loading

cuonglm commented Oct 14, 2022 • edited Loading

mjl- commented Oct 14, 2022

cherrymui commented Oct 14, 2022 • edited Loading

cherrymui commented Oct 14, 2022

cherrymui commented Oct 15, 2022

gopherbot commented Oct 15, 2022

cherrymui commented Oct 20, 2022

gopherbot commented Oct 20, 2022

gopherbot commented Oct 24, 2022

gopherbot commented Oct 24, 2022

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

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

elagergren-spideroak commented Sep 22, 2022 •

edited

Loading

mjl- commented Oct 14, 2022 •

edited

Loading

cuonglm commented Oct 14, 2022 •

edited

Loading

cherrymui commented Oct 14, 2022 •

edited

Loading