#!stacks
"sigpanic" && "golang.org/x/telemetry/internal/counter.(*Counter).add:=274"

Issue created by stacks.

I suspect this is another case of gopls heap corruption, but haven't investigate yet.

This stack wbY-eA was reported by telemetry:

golang.org/x/tools/gopls@v0.18.1 go1.24.3 linux/amd64 vscode (1)

Comment From: findleyr

Err, yeah, this looks like heap corruption (a throw in atomic.CompareAndSwap?).

Moving to the backlog. Also, this is a crash in v0.18.1, not v0.19.x.

Comment From: findleyr

@golang/runtime does the nominal stack of this panic, in SIGBUS, or the fact that it occurred in an atomic operation, indicate a particular form of memory corruption?

Comment From: cherrymui

Given that telemetry mmaps files, a SIGBUS may be from that it fails to write to that mmap'd memory, somehow.

Comment From: cherrymui

I don't know if this is related at all, but SIGBUS+mmap reminds me a linker issue: the linker uses mmap to write the output file. If the machine's disk space is low, the file creation, resizing, and mmap operations would all succeed, but when actually writing to the mmap'd memory, it will get a SIGBUS, presumably because the kernel cannot create a file backing store for the write. We fixed that by preallocating file storage (using fallocate).

This would only be an issue if this is writing to a newly created or grown file, or to a hole in the file (that used to contain a block of zeros).