runtime: /usr/local/go/src/runtime/mpagealloc.go:496 index out of range

[ltYang]

Go version

go version go1.22.7 linux/amd64

Output of go env in your module/workspace:

GO111MODULE='on'
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.7'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='0'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1692981606=/tmp/go-build -gno-record-gcc-switches'

What did you do?

The service image I built using Golang: 1.22.7 runs in Alpine: 3.20, and this error is caused by my business system continuously receiving web requests. My web framework is in gin, and my business code is not included in the stack information, so I suspect that a bug in Go may have been triggered.And I checked that the reason for pod exit was not due to memory overflow。

What did you see happen?

fatal error: index out of range

runtime stack:
runtime.throw({0x1316d95?, 0xc000d13950?})
/usr/local/go/src/runtime/panic.go:1023 +0x5c fp=0xc000d13920 sp=0xc000d138f0 pc=0x43e07c
runtime.panicCheck1(0x0?, {0x1316d95, 0x12})
/usr/local/go/src/runtime/panic.go:58 +0x94 fp=0xc000d13940 sp=0xc000d13920 pc=0x43bfd4
runtime.goPanicIndexU(0x20002030002, 0x2030028)
/usr/local/go/src/runtime/panic.go:119 +0x2e fp=0xc000d13980 sp=0xc000d13940 pc=0x43c12e
runtime.(*pageAlloc).update(0x1e7ea48, 0x1?, 0x1?, 0x1?, 0x0?)
/usr/local/go/src/runtime/mpagealloc.go:496 +0x41a fp=0xc000d13a40 sp=0xc000d13980 pc=0x430c7a
runtime.(*pageAlloc).allocToCache(0x1e7ea48)
/usr/local/go/src/runtime/mpagecache.go:168 +0x236 fp=0xc000d13aa8 sp=0xc000d13a40 pc=0x4338d6
runtime.(*mheap).allocSpan(0x1e7ea40, 0x4, 0x3, 0x0)
/usr/local/go/src/runtime/mheap.go:1192 +0x87 fp=0xc000d13b48 sp=0xc000d13aa8 pc=0x42e2e7
runtime.(*mheap).allocManual(0x45f119?, 0x47a6cd?, 0x0?)
/usr/local/go/src/runtime/mheap.go:990 +0x19 fp=0xc000d13b70 sp=0xc000d13b48 pc=0x42def9
runtime.getempty.func1()
/usr/local/go/src/runtime/mgcwork.go:378 +0x2d fp=0xc000d13ba0 sp=0xc000d13b70 pc=0x42cd4d
runtime.getempty()
/usr/local/go/src/runtime/mgcwork.go:377 +0xcc fp=0xc000d13c00 sp=0xc000d13ba0 pc=0x42cbec
runtime.(*stackScanState).putPtr(0xc000170060?, 0xc00014a7a0, 0x0?)
/usr/local/go/src/runtime/mgcstack.go:213 +0x90 fp=0xc000d13c28 sp=0xc000d13c00 pc=0x429f90
runtime.scanblock(0xc00014a760, 0x58, 0x13cf450, 0xc000070668, 0xc000d13d88)
/usr/local/go/src/runtime/mgcmark.go:1379 +0xd2 fp=0xc000d13c88 sp=0xc000d13c28 pc=0x425612
runtime.scanframeworker(0xc000d13d28, 0xc000d13d88, 0xc000070668)
/usr/local/go/src/runtime/mgcmark.go:1069 +0xae fp=0xc000d13ce8 sp=0xc000d13c88 pc=0x424d4e
runtime.scanstack(0xc000182540, 0xc000070668)
/usr/local/go/src/runtime/mgcmark.go:900 +0x267 fp=0xc000d13e18 sp=0xc000d13ce8 pc=0x424787
runtime.markroot.func1()
/usr/local/go/src/runtime/mgcmark.go:241 +0xb5 fp=0xc000d13e68 sp=0xc000d13e18 pc=0x423455
runtime.markroot(0xc000070668, 0x3a, 0x1)
/usr/local/go/src/runtime/mgcmark.go:215 +0x1a8 fp=0xc000d13f10 sp=0xc000d13e68 pc=0x4230e8
runtime.gcDrain(0xc000070668, 0x3)
/usr/local/go/src/runtime/mgcmark.go:1200 +0x3d4 fp=0xc000d13f78 sp=0xc000d13f10 pc=0x4252b4
runtime.gcDrainMarkWorkerDedicated(...)
/usr/local/go/src/runtime/mgcmark.go:1124
runtime.gcBgMarkWorker.func2()
/usr/local/go/src/runtime/mgc.go:1387 +0xa5 fp=0xc000d13fc8 sp=0xc000d13f78 pc=0x421745
runtime.systemstack(0x0)
/usr/local/go/src/runtime/asm_amd64.s:509 +0x4a fp=0xc000d13fd8 sp=0xc000d13fc8 pc=0x476e8a

What did you expect to see?

Service exit caused by non business code during runtime, even if there is a panic according to the service settings, should still be captured by the defer of the gin framework。

[gabyhelp]

Related Issues

• runtime: fatal error: index out of range #73646 (closed)
• runtime: index out of range panic, runtime.heapBitsForAddr #46728 (closed)
• runtime: slice bounds out of range: panic during panic #44075 (closed)
• fatal error: out of memory #13728 (closed)
• runtime: TestStackOverflow panics on linux #11049 (closed)
• runtime: panic (slice bounds out of range) in runtime.gcInstallStackBarrier #11080 (closed)
• fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x2 addr=0xc002000000 pc=0x46e698] Linux version 5.10.135-yocto-standard #58377 (closed)
• runtime: huge page fragmentation on Linux leads to out of memory #12233 (closed)
• debug/pe: fatal error: runtime: out of memory on NewFile #43827
• runtime: failed MSpanList_Remove, integer divide by zero #31379 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

go1.22.7 is no longer supported. Please upgrade to a supported version (1.23+) and see if you still get the failure.

It would also be a good idea to rule out a data race as the cause. Could you run with -race?

I'm going to close for now. Feel free to reopen with an updated report on 1.23 or 1.24.