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

reflect: MakeMap() and not native map type wrong behavior [1.14 backport] #37721

Closed
gopherbot opened this issue Mar 6, 2020 · 5 comments
Closed
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone

Comments

@gopherbot
Copy link

@randall77 requested issue #37716 to be considered for backport to the next 1.14 minor release.

@gopherbot please open a backport issue for 1.14.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Mar 6, 2020
@gopherbot gopherbot added this to the Go1.14.1 milestone Mar 6, 2020
@randall77
Copy link
Contributor

This issue is serious enough to warrant backporting to 1.14. In certain situations maps lookups will fail.

There are possible workarounds, but they are kind of hacky (define an unused variable of the correct concrete map type, and make sure to add a use of it that the linker can't remove). Moreover, you have to know to use a workaround - the bug itself just results in map lookups randomly failing, which makes it hard to realize you're even affected by this bug.

@gopherbot
Copy link
Author

Change https://golang.org/cl/222778 mentions this issue: [release-branch.go1.14] runtime: make typehash match compiler generated hashes exactly

@gopherbot
Copy link
Author

Change https://golang.org/cl/222779 mentions this issue: [release-branch.go1.14] runtime: special case interface hashing for pointers

@toothrot
Copy link
Contributor

Approving as this is a serious issue with no viable workaround.

@toothrot toothrot added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Mar 10, 2020
@gopherbot
Copy link
Author

Closed by merging 6717d27 to release-branch.go1.14.

gopherbot pushed a commit that referenced this issue Mar 10, 2020
…ointers

Interfaces often contain pointers. Implement a fast path for this case.

name                   old time/op  new time/op  delta
MapInterfaceString-16  21.4ns ±19%  20.5ns ±10%     ~     (p=0.361 n=10+10)
MapInterfacePtr-16     25.8ns ± 8%  17.3ns ± 7%  -33.11%  (p=0.000 n=10+9)

We need this CL as well to fix 37721.
Update #37721
Fixes #37613

Change-Id: Ice52820e6259a3edeafcbbbeb25b1e363bef00d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/219338
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit afd691c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222779
Run-TryBot: Alexander Rakoczy <alex@golang.org>
gopherbot pushed a commit that referenced this issue Mar 10, 2020
…ed hashes exactly

If typehash (used by reflect) does not match the built-in map's hash,
then problems occur. If a map is built using reflect, and then
assigned to a variable of map type, the hash function can change. That
causes very bad things.

This issue is rare. MapOf consults a cache of all types that occur in
the binary before making a new one. To make a true new map type (with
a hash function derived from typehash) that map type must not occur in
the binary anywhere. But to cause the bug, we need a variable of that
type in order to assign to it. The only way to make that work is to
use a named map type for the variable, so it is distinct from the
unnamed version that MapOf looks for.

Fixes #37721

Change-Id: I3537bfceca8cbfa1af84202f432f3c06953fe0ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/222357
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 2b8e60d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222778
@golang golang locked and limited conversation to collaborators Mar 10, 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
Projects
None yet
Development

No branches or pull requests

3 participants