runtime: memory corruption leading to panic on linux/riscv64

[Ikke]

Go version

go version go1.26.1 linux/riscv64

Output of go env in your module/workspace:

AR='ar'
CC='cc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='c++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='riscv64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/buildozer/aports/community/opentofu/tmp/go'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/buildozer/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS='-buildmode=pie -modcacherw -trimpath -buildvcs=false'
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/home/buildozer/aports/community/opentofu/tmp/go-build3937398104=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='riscv64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/buildozer/aports/community/opentofu/tmp/go'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/buildozer/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GORISCV64='rva20u64'
GOROOT='/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/buildozer/.config/go/telemetry'
GOTMPDIR='/home/buildozer/aports/community/opentofu/tmp'
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_riscv64'
GOVCS=''
GOVERSION='go1.26.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Running the opentofu test suite on Alpine Linux on a riscv64 (MilkV Pioneer) , we run into a panic deep inside the fmt package.

stack trace

panic: runtime error: invalid memory address or nil pointer dereference [recovered, repanicked]
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1 pc=0x2aca9e6cfe]

goroutine 98 [running]:
testing.tRunner.func1.2({0x2acd5cf480, 0x2acdac1880})
        testing/testing.go:1974 +0x168
testing.tRunner.func1()
        testing/testing.go:1977 +0x244
panic({0x2acd5cf480?, 0x2acdac1880?})
        runtime/panic.go:860 +0x104
fmt.(*buffer).writeString(...)
        fmt/print.go:108
fmt.(*fmt).padString(0x2acaa532a2?, {0x1, 0x1})
        fmt/format.go:113 +0x86
fmt.(*fmt).fmtS(0x3f4757b828?, {0x1?, 0x7?})
        fmt/format.go:359 +0x42
fmt.(*pp).fmtString(0x0?, {0x1?, 0x0?}, 0x3?)
        fmt/print.go:498 +0xe2
fmt.(*pp).printArg(0x3f472ce9c0, {0x2acd4c2160, 0x3f47b81460}, 0x73)
        fmt/print.go:742 +0x4b0
fmt.(*pp).doPrintf(0x3f472ce9c0, {0x2acbe0f044, 0xf}, {0x3f46f9d7b8, 0x2, 0x2})
        fmt/print.go:1075 +0x2a2
fmt.Sprintf({0x2acbe0f044, 0xf}, {0x3f46f9d7b8, 0x2, 0x2})
        fmt/print.go:239 +0x4a
github.com/opentofu/opentofu/internal/addrs.Resource.String({{}, 0x47112da0, {0x1, 0x1}, {0x4d, 0x2acbe09ec0}})
        github.com/opentofu/opentofu/internal/addrs/resource.go:37 +0xf8
github.com/opentofu/opentofu/internal/addrs.ResourceInstance.String({{}, {{}, 0x47112da0, {0x1, 0x1}, {0x4d, 0x2acbe09ec0}}, {0x2acda53520, 0x2acda12200}})
        github.com/opentofu/opentofu/internal/addrs/resource.go:122 +0x74
github.com/opentofu/opentofu/internal/addrs.AbsResourceInstance.String({{}, {0x3f47112da0, 0x1, 0x1}, {{}, {{}, 0x47112da0, {0x1, 0x1}, {0x4d, ...}}, ...}})
        github.com/opentofu/opentofu/internal/addrs/resource.go:331 +0x92
github.com/opentofu/opentofu/internal/command/jsonentities.NewResourceAddr({{}, {0x3f47112da0, 0x1, 0x1}, {{}, {{}, 0x47112da0, {0x1, 0x1}, {0x4d, ...}}, ...}})
        github.com/opentofu/opentofu/internal/command/jsonentities/resource_addr.go:31 +0xfa
github.com/opentofu/opentofu/internal/command/jsonentities.NewResourceInstanceChange(0x3f46f9dd80)
        github.com/opentofu/opentofu/internal/command/jsonentities/change.go:38 +0x7cc
github.com/opentofu/opentofu/internal/command/views.TestJSONView_PlannedChange(0x3f471d0fc8)
        github.com/opentofu/opentofu/internal/command/views/json_view_test.go:198 +0x4ac
testing.tRunner(0x3f471d0fc8, 0x2acda0b918)
        testing/testing.go:2036 +0xc4
created by testing.(*T).Run in goroutine 1
        testing/testing.go:2101 +0x38a
FAIL    github.com/opentofu/opentofu/internal/command/views     1.270s

The panic starts from a code path that should never happen.

Printing PrevRunAddr in TestJSONView_PlannedChange results in the same panic.

Printing cs.PrevRunAddr.Resource.Resource.Mode shows: ResourceMode(1342943200), an invalid value. The value 77 (ascii 'M') is expected.

Interestingly, if I add managed.Instance(addrs.StringKey("boop")).Absolute(foo) (not assigning it, just a statement on its down), then the issue appears to fixed.

I'm happy to provide more details if necessary.

What did you see happen?

Failing test, panic, memory corruption

What did you expect to see?

None of the above

[lotheac]

Running the test with -gcflags '-l' seems to help; perhaps the memory corruption is related to inlining (since -l disables inlining).

[gabyhelp]

Related Issues

• reflect: k8s unit tests on ppc64le sees SEGV fault with tip #48238 (closed)
• runtime: race detector crash on ppc64le #76051 (closed)
• test: Test fail on riscv64 Alpine Linux starting with Go 1.24.2 #73265 (closed)
• cmd/link: panic on riscv64 with CGO enabled due to empty container symbol #72840 (closed)
• runtime: jsoniter stack corruption with 32-bit arches, potential GC issues with 64-bit arches #71408 (closed)
• cmd/go: panic in cmd/go/internal/cache.(*DiskCache).markUsed #70600 (closed)
• runtime: function textOff returns incorrect value if multiple text sections are present #35207 (closed)
• runtime: go1.22.0 test with -race will SIGSEGV or SIGBUS or Bad Pointer #65783 (closed)

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

[dmitshur]

Thanks for the report. Does this happen only on the linux/riscv64 port specifically, or are you able to reproduce it on other ports too?

CC @golang/riscv64.

[lotheac]

we have not seen failures on any other architecture. we specifically only added -gcflags -l scoped only to riscv64 to resolve our immediate issue; our other architectures all worked without modification.