Open
Description
#!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/gopls@v0.17.1 go1.23.4 windows/amd64 vscode (1)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
gabyhelp commentedon Dec 30, 2024
Related Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
mknyszek commentedon Jan 15, 2025
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.
[-]runtime: fatal "cannot allocate memory" throw in bgsweep goroutine (windows)[/-][+]gopls: out-of-memory failure on Windows[/+][-]gopls: out-of-memory failure on Windows[/-][+]x/tools/gopls: out-of-memory failure on Windows[/+]findleyr commentedon Jan 16, 2025
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)