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: "fatal error: unexpected signal" 0xC0000005 on Windows for a small program with a large allocation [1.13 backport] #37483

Closed
dmitshur opened this issue Feb 26, 2020 · 3 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone

Comments

@dmitshur
Copy link
Contributor

@aclements requested issue #37470 to be considered for backport to the next 1.13 minor release.

@gopherbot, ple​ase open a backport to Go 1.14 and Go 1.15 1.13.

@dmitshur
Copy link
Contributor Author

dmitshur commented Mar 5, 2020

Approving because this is a serious problem (crash in rare but specific cases) with no workaround.

@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Mar 5, 2020
@cagedmantis cagedmantis modified the milestones: Go1.13.9, Go1.13.10 Mar 19, 2020
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/224418 mentions this issue: [release-branch.go1.13] runtime: fix rounding in materializeGCProg

@gopherbot
Copy link
Contributor

Closed by merging 3a275aa to release-branch.go1.13.

gopherbot pushed a commit that referenced this issue Apr 7, 2020
materializeGCProg allocates a temporary buffer for unrolling a GC
program. Unfortunately, when computing the size of the buffer, it
rounds *down* the number of bytes needed to store bitmap before
rounding up the number of pages needed to store those bytes. The fact
that it rounds up to pages usually mitigates the rounding down, but
the type from #37470 exists right on the boundary where this doesn't
work:

type Sequencer struct {
	htable [1 << 17]uint32
	buf    []byte
}

On 64-bit, this GC bitmap is exactly 8 KiB of zeros, followed by three
one bits. Hence, this needs 8193 bytes of storage, but the current
math in materializeGCProg rounds *down* the three one bits to 8192
bytes. Since this is exactly pageSize, the next step of rounding up to
the page size doesn't mitigate this error, and materializeGCProg
allocates a buffer that is one byte too small. runGCProg then writes
one byte past the end of this buffer, causing either a segfault (if
you're lucky!) or memory corruption.

Updates #37470.
Fixes #37483.

Change-Id: Iad24c463c501cd9b1dc1924bc2ad007991a094a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/224418
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@golang golang locked and limited conversation to collaborators Apr 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
3 participants