x/tools/gopls: growslice crashes while zeroing

[adonovan]

#!stacks
"sigpanic" && "memclrNoHeapPointers" && "growslice" && "binary.AppendUvarint" && "typeindex.New-range1"

Issue created by stacks.

This stack kvhPfw was reported by telemetry:

• crash/crash
• runtime.throw:+9,+0x37
• runtime.sigpanic:+16,+0x16f
• runtime.memclrNoHeapPointers:+42,+0x58
• runtime.growslice:+92,+0x4df
• encoding/binary.AppendUvarint:=46,+0x3a3
• honnef.co/go/tools/internal/typesinternal/typeindex.New-range1:+30,+0x25c
• golang.org/x/tools/go/ast/inspector.Cursor.Preorder.func1:+6,+0xbf
• honnef.co/go/tools/internal/typesinternal/typeindex.New:+15,+0x1d3
• honnef.co/go/tools/internal/analysisinternal/typeindex.init.func1:+2,+0x5b
• golang.org/x/tools/gopls/internal/cache.(*action).exec.func6:+31,+0x8b
• golang.org/x/tools/gopls/internal/cache.(*action).exec:+199,+0x883
• golang.org/x/tools/gopls/internal/cache.execActions.func1.1:+2,+0x4f
• sync.(*Once).doSlow:+5,+0xef
• sync.(*Once).Do:=69,+0x7f
• golang.org/x/tools/gopls/internal/cache.execActions.func1:+2,+0x50
• runtime.goexit:+0,+0x3

golang.org/x/tools/gopls@v0.20.0 go1.24.5 darwin/arm64 vscode (1)

[adonovan]

This crash occurs when zeroing memory returned by malloc. That means one of:

(a) gopls has trampled on malloc's data structures;
(b) malloc has a bug; or
(c) a hardware failure has changed the value of registers or memory.

I wonder whether we're just seeing the normal background radiation of hardware faults. @prattmic

[gabyhelp]

Related Issues

• x/tools/gopls: analysisinternal.ZeroValue crash on (presumably) unsafe.Pointer #70585 (closed)
• x/tools/gopls: nil deref in x/telemetry/internal/counter.(*Counter).add #73890
• x/tools/gopls: "slice bounds out of range" crash in ExtractToNewFile #70553
• x/tools/gopls: automated issue report (crash) #40819 (closed)
• x/tools/gopls: SEGV in HasSuffix (corrupt string) #74348
• x/tools/gopls: CodeActions: "end < start" panic #74394 (closed)
• x/tools/gopls: crash in append (invalid string data pointer) #73586
• x/tools/gopls: SEGV while clearing memory in newobject #71561
• x/tools/gopls: out of memory (crash) #42889 (closed)
• x/tools/gopls: Inline call: panic in reflect.Value.Set #74653

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

[Jorropo]

Is there a magic incantation of stacks to get all the stacks matching this ?
I want stats about GOOS/GOARCH pairs.

[adonovan]

Is there a magic incantation of stacks to get all the stacks matching this ? I want stats about GOOS/GOARCH pairs.

Not really. A note about the stacks process:

The particular stack above was seen only once, as indicated by the (1), in that week's telemetry, on a mac. If an identical stack appears in future, the tool won't take any action on the issue, so we won't know anything about it. If a variant that matches the #!stacks predicate should appear, the tool will add a new note on the issue, along with its counts of failures the week it was reported.

In short, this tool is really intended to display unique stack traces, and doesn't give us good quantitative information. We could write a tool to re-scan all the stacks to get the most complete quantitative picture though; that's a good idea.

If you're asking about the whole class of these weird crashes in gopls, the gopls/memory-corruption label and its parent issue #71425 will give you an overview. For a long time [see here], all crashes were on linux/amd64 with a particular Go toolchain, raising the question of whether a single faulty machine was the sole source. But we've started to see darwin/arm64 stacks too (as above).

[prattmic]

For what it's worth, stacks is pretty easy to hack on, so making modifications to do a one-off recount of stacks shouldn't be too hard. Just make sure to pass -n to avoid posting to issues.