Skip to content
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

Open
bcmills opened this issue Jun 27, 2022 · 1 comment
Open

runtime,cmd/go: runtime: out of memory in runtime.sysMapOS #53576

bcmills opened this issue Jun 27, 2022 · 1 comment
Labels
compiler/runtime NeedsInvestigation OS-OpenBSD
Milestone

Comments

@bcmills
Copy link
Member

bcmills commented Jun 27, 2022

fatal error: runtime: out of memory

runtime stack:
runtime.throw({0xa25205?, 0x20000?})
	/tmp/workdir/go/src/runtime/panic.go:1047 +0x5d fp=0x243c4b248 sp=0x243c4b218 pc=0x43621d
runtime.sysMapOS(0xc001400000, 0xc000800000?)
	/tmp/workdir/go/src/runtime/mem_bsd.go:71 +0x11b fp=0x243c4b290 sp=0x243c4b248 pc=0x41975b
runtime.sysMap(0xe46c80?, 0x21b3a8000?, 0x42cb80?)
	/tmp/workdir/go/src/runtime/mem.go:142 +0x35 fp=0x243c4b2c0 sp=0x243c4b290 pc=0x419595
runtime.(*mheap).grow(0xe46c80, 0x6000292?)
	/tmp/workdir/go/src/runtime/mheap.go:1459 +0x23d fp=0x243c4b330 sp=0x243c4b2c0 pc=0x429c3d
runtime.(*mheap).allocSpan(0xe46c80, 0x6000292, 0x0, 0x1)
	/tmp/workdir/go/src/runtime/mheap.go:1191 +0x2e6 fp=0x243c4b3e0 sp=0x243c4b330 pc=0x4293c6
runtime.(*mheap).alloc.func1()
	/tmp/workdir/go/src/runtime/mheap.go:910 +0x65 fp=0x243c4b428 sp=0x243c4b3e0 pc=0x428d25
runtime.systemstack()
	/tmp/workdir/go/src/runtime/asm_amd64.s:492 +0x49 fp=0x243c4b430 sp=0x243c4b428 pc=0x464729

I notice that sysMapOS and sysReserveOS on BSD both invoke mmap, and cmd/go has recently started using syscall.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.

  1. Perhaps a bug in cmd/go (perhaps on the indexing path) is causing it to use more memory than expected?
  2. Perhaps a bug in the OpenBSD mmap implementation causes the cmd/go call to syscall.Mmap to steal an address that was supposed to be reserved for the runtime?
  3. Perhaps a bug somewhere in the runtime causes it to drastically overshoot the heap target? (But I would expect the syscall.Mmap usage to instead cause it to undershoot, since the heap size used to compute GOGC 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)

@bcmills bcmills added OS-OpenBSD NeedsInvestigation labels Jun 27, 2022
@bcmills bcmills added this to the Backlog milestone Jun 27, 2022
@bcmills
Copy link
Member Author

bcmills commented Jun 27, 2022

Leaving on the backlog for now to see whether a pattern emerges. (Would be useful to know whether this failure mode is GOOS-specific.)

@gopherbot gopherbot added the compiler/runtime label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime NeedsInvestigation OS-OpenBSD
Projects
Status: Triage Backlog
Development

No branches or pull requests

2 participants