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

Issue created by stacks.

This stack kvhPfw was reported by telemetry:

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

Comment From: 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

Comment From: gabyhelp

Related Issues

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

Comment From: Jorropo

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

Comment From: 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).

Comment From: 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.