diff options
author | Michael Anthony Knyszek <mknyszek@google.com> | 2024-04-19 04:41:01 +0000 |
---|---|---|
committer | Gopher Robot <gobot@golang.org> | 2024-04-19 17:16:47 +0000 |
commit | 4324d5a88cf8ac1d6cf1cb57f5df82ddd6c6283e (patch) | |
tree | 7b5d9de116b21b9cc4a5f732531604843b23ad9e /src/cmd/trace/v2/main.go | |
parent | 2ff89341f643920f827e4c45db8e4b507fedd9f0 (diff) | |
download | go-4324d5a88cf8ac1d6cf1cb57f5df82ddd6c6283e.tar.gz go-4324d5a88cf8ac1d6cf1cb57f5df82ddd6c6283e.zip |
internal/concurrent: handle boundary case for hash bits in HashTrieMap
Currently the HashTrieMap has a panic for running out of hash bits, but
it turns out we can end up in these paths in valid cases, like inserting
or deleting an element that requires *all* the hash bits to finds its
position in the tree. There's basically an off-by-one error here where
the panic fires erroneously.
This wasn't caught before the original CL landed because it's very
unlikely on 64-bit platforms, with a 64-bit hash, but much more likely
on 32-bit platforms, where using all 32 bits of a 32-bit hash is much
more likely.
This CL makes the condition for panicking much more explicit, which
avoids the off-by-one error.
After this CL, I can't get the tests to fail on 32-bit under stress
testing.
Change-Id: I855e301e3b3893e2b6b017f6dd9f3d83a94a558d
Reviewed-on: https://go-review.googlesource.com/c/go/+/580138
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Diffstat (limited to 'src/cmd/trace/v2/main.go')
0 files changed, 0 insertions, 0 deletions