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: possible pointer-to-random-memory during hashmap evacuate #21459

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

Comments

Projects
None yet
4 participants
@josharian
Copy link
Contributor

commented Aug 15, 2017

@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

This comment has been minimized.

Copy link

commented Aug 15, 2017

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

@dsnet

This comment has been minimized.

Copy link
Member

commented Aug 15, 2017

How long has this bug been in existence?

@randall77

This comment has been minimized.

Copy link
Contributor

commented Aug 15, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2017

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.

@randall77 randall77 closed this Aug 18, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Aug 18, 2017

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

runtime: no need to protect key/value increments against end of bucket
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.
You can’t perform that action at this time.