-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime,cmd/go: runtime: out of memory
in runtime.sysMapOS
#53576
Comments
Leaving on the backlog for now to see whether a pattern emerges. (Would be useful to know whether this failure mode is GOOS-specific.) |
I'm experiencing a similar issue while running
Of note: this is on linux, not BSD. I haven't been able to find a minimal example yet (the project in question is unfortunately not small), but one interesting detail that might be interesting: cleaning the cache via This affected at least 1.19 and 1.20. |
I'm experimenting a SIGSEGV, launching woodpecker server 1.15.7 from my Debian 11.6, |
Found new dashboard test flakes for:
2023-11-16 19:26 openbsd-386-72 go@d573a8a8 runtime/trace.TestTraceCPUProfile (log)
|
Found new dashboard test flakes for:
2023-11-20 15:56 openbsd-386-72 go@1d187fd0 runtime/trace (log)
|
Found new dashboard test flakes for:
2023-11-21 16:29 openbsd-386-72 go@78d037b0 runtime/trace (log)
|
Found new dashboard test flakes for:
2023-11-21 17:59 openbsd-386-72 go@070139a1 runtime/trace (log)
|
Found new dashboard test flakes for:
2023-11-21 20:34 openbsd-386-72 go@00715d08 runtime/trace (log)
|
Found new dashboard test flakes for:
2023-11-21 21:27 openbsd-386-72 go@351d8520 runtime/trace (log)
2023-11-21 21:27 openbsd-386-72 go@48a6362d runtime/trace (log)
2023-11-21 21:29 openbsd-386-72 go@90ba4452 runtime/trace (log)
|
Found new dashboard test flakes for:
2024-02-02 16:26 openbsd-386-72 go@2fdad8af runtime/trace.TestTraceCPUProfile (log)
|
Found new dashboard test flakes for:
2024-04-26 18:12 gotip-openbsd-amd64 go@b384ee7c cmd/link/internal/ld.TestDeadcode/ifacemethod6 (log)
|
Found new dashboard test flakes for:
2024-06-24 16:57 go1.22-openbsd-amd64 release-branch.go1.22@179ccb70 cmd/link/internal/ld.TestDeadcode/ifacemethod3 (log)
|
Found new dashboard test flakes for:
2024-10-02 00:57 gotip-openbsd-amd64 go@aa42d7b4 cmd/link/internal/ld.TestDeadcode/ifacemethod (log)
|
Found new dashboard test flakes for:
2024-10-07 16:38 gotip-openbsd-amd64 go@05d8a33b cmd/link/internal/ld.TestDeadcode/ifacemethod2 (log)
|
Found new dashboard test flakes for:
2024-11-18 20:29 gotip-openbsd-amd64 go@4804d0da cmd/link/internal/ld.TestDeadcode/globalmap (log)
|
Found new dashboard test flakes for:
2024-11-20 17:58 gotip-openbsd-amd64 go@5165f541 cmd/link/internal/ld.TestDeadcode/globalmap (log)
|
Found new dashboard test flakes for:
2025-01-03 00:10 gotip-openbsd-amd64 go@4b652e9f cmd/link/internal/ld.TestDeadcode/ifacemethod (log)
|
Found new dashboard test flakes for:
2025-01-09 21:59 gotip-openbsd-amd64 go@d0c9142c cmd/link/internal/ld.TestDeadcode/ifacemethod6 (log)
|
I notice that
sysMapOS
andsysReserveOS
on BSD both invokemmap
, andcmd/go
has recently started usingsyscall.Mmap
to access cached metadata during package loading.I can think of the following possible explanations, but I'm not sure which (if any) is correct.
cmd/go
(perhaps on the indexing path) is causing it to use more memory than expected?mmap
implementation causes thecmd/go
call tosyscall.Mmap
to steal an address that was supposed to be reserved for the runtime?syscall.Mmap
usage to instead cause it to undershoot, since the heap size used to computeGOGC
will not include the Mmap'd data.)This is another case where it would be really helpful to have some heap stats from the runtime when the process OOMs (#52546)...
(CC @golang/openbsd @golang/runtime)
The text was updated successfully, but these errors were encountered: