x/tools/gopls: out-of-memory failure on Windows

[adonovan]

#!stacks
"runtime.bgsweep" && "runtime.newArenaMayUnlock:+6" && "runtime.throw"

Issue created by stacks.

I suspect this is another manifestation of #70445, but I thought I should report it since the call stack is completely different.

This stack F860lA was reported by telemetry:

• crash/crash
• runtime.throw:+9
• runtime.newArenaMayUnlock:+6
• runtime.newMarkBits:+22
• runtime.(*sweepLocked).sweep:+185
• runtime.sweepone:+37
• runtime.bgsweep:+28
• runtime.gcenable.gowrap1:+0
• runtime.goexit:+0

golang.org/x/tools/[email protected] go1.23.4 windows/amd64 vscode (1)

[gabyhelp]

Related Issues

• x/tools/gopls: OOM reported by fatal in runtime.mallocgc (windows) #70445 (closed)
• runtime: fatal error: sweep increased allocation count go 1.10.1 windows/amd64 #24881 (closed)
• runtime: sweep increased allocation count #19473 (closed)
• runtime: fatal error: MSpanList_Remove #14831 (closed)
• runtime: fatal: cannot map pages in arena address space #19514 (closed)
• runtime/race: windows race out of memory allocating heap arena map #28497
• runtime: fatal error: sweep increased allocation count #15762 (closed)
• runtime: fatal error: sweep increased allocation count in go1.7 #16778 (closed)
• runtime: "sweep increased allocation count" when using reflect.Call #21717 (closed)
• runtime: an application using DLL crashes on windows #9885 (closed)

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

[mknyszek]

This just seems like a regular OOM. On Windows all system-allocated memory must be committed up-front, so syscalls actually start failing (unlike Linux, where page faults try to page in more physical memory and that's the signal). So, it's impossible to tell from this whether the OOM is due to the person running gopls just ate up their own memory with various apps or gopls was using too much memory, unfortunately. But we don't think this is a bug in the runtime.

[findleyr]

Keeping this open but moving to the backlog, since it is currently unactionable.
(I'd close it, but absent other mechanisms to track OOMs, let's keep recording stacks here)