go: runtime: arena mapping creates large core files and bad mlockall behavior

package main

var p *int

func main() {
	*p = 0
}

Run with

$ ulimit -c unlimited
$ GOTRACEBACK=crash go run test.go
$ ls -l core

Go 1.11 and tip generate a ~100MB core. Go 1.10 and earlier only generate a ~2MB core. Probably related to the arena changes in 1.11.

@aclements @heschik @hyangah

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 1
Comments: 16 (10 by maintainers)

Commits related to this issue

internal/gocore: update to handle 1.12 core files Just a few adjustments to handle runtime changes. Use zip files for test data so we don't use so much disk space for large core files. See golang/go... — committed to golang/debug by randall77 5 years ago

Most upvoted comments

Do we have a fix in mind? If not, does the benefit of that change outweigh the regression in core sizes?

Map arenas PROT_NONE initially and incrementally re-map them PROT_READ|PROT_WRITE as we need more space. We only need to keep track of the “current arena” and how far we’ve mapped it (any other arena can be fully mapped).

I don’t think this is very hard to implement or adds much complexity, though everything in sysAlloc is a little tricky.

aclements on Oct 23, 2018