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

Jump to bottom

runtime: possible pointer-to-random-memory during hashmap evacuate #21459

Closed
josharian opened this issue Aug 15, 2017 · 5 comments
Closed

runtime: possible pointer-to-random-memory during hashmap evacuate #21459

josharian opened this issue Aug 15, 2017 · 5 comments
Labels
FrozenDueToAge
Milestone
Go1.9

Comments

@josharian
Copy link
Contributor

josharian commented Aug 15, 2017 •
edited

@randall77 noted while reviewing CL 54653 that we might generate a pointer past the end of a map bucket.

This has been fixed for 1.10, in CL 54653. This issue is to discuss whether we want to also fix it for 1.9.

cc @randall77 @broady
@josharian josharian changed the title runtime runtime: possible pointer-to-random-memory during hashmap evacuate Aug 15, 2017
@josharian josharian added this to the Go1.9 milestone Aug 15, 2017
@gopherbot
Copy link

Change https://golang.org/cl/55890 mentions this issue: [release-branch.go1.9] runtime: prevent pointer-past-end during map growth

@dsnet
Copy link
Member

dsnet commented Aug 15, 2017

How long has this bug been in existence?

@randall77
Copy link
Contributor

Probably since the GC cared about invalid pointers (1.6?).

It's a very hard bug to trigger. You'd have to be evacuating to the last bucket in an array of map buckets, or an overflow bucket, be evacuating just the right number of elements, and get interrupted at just the right time.

But if it did trigger it would be one of those annoying and hard to track down "sweep increased allocation count" bugs.

The fix is super simple.

@randall77 randall77 mentioned this issue Aug 18, 2017
Closed
@randall77
Copy link
Contributor

We pushed the overflow pointer to the end of the bucket a while ago to solve exactly this sort of problem, so this actually isn't a bug. Even if the pointer points past the end of the value array, it doesn't point past the end of the bucket.
So no fix needed.

@gopherbot
Copy link

Change https://golang.org/cl/56772 mentions this issue: runtime: no need to protect key/value increments against end of bucket

gopherbot pushed a commit that referenced this issue Aug 18, 2017
@randall77
runtime: no need to protect key/value increments against end of bucket
77871cc 
After the key and value arrays, we have an overflow pointer.
So there's no way a past-the-end key or value pointer could point
past the end of the containing bucket.

So we don't need this additional protection.

Update #21459

Change-Id: I7726140033b06b187f7a7d566b3af8cdcaeab0b0
Reviewed-on: https://go-review.googlesource.com/56772
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Avelino <t@avelino.xxx>
@golang golang locked and limited conversation to collaborators Aug 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.9
Development

No branches or pull requests
4 participants
@josharian @dsnet @randall77 @gopherbot