Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upruntime: hashmap iterator start position not random enough #8688
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
gopherbot
commented
Sep 9, 2014
CL https://golang.org/cl/135660043 mentions this issue. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
This issue was closed by revision 251daf8. Status changed to Fixed. |
rsc
added
fixed
labels
Sep 9, 2014
rsc
added this to the Go1.4 milestone
Apr 14, 2015
rsc
removed
the
release-go1.4
label
Apr 14, 2015
golang
locked and limited conversation to collaborators
Jun 25, 2016
gopherbot
added
the
FrozenDueToAge
label
Jun 25, 2016
added a commit
to wheatman/go-akaros
that referenced
this issue
Jun 25, 2018
added a commit
to wheatman/go-akaros
that referenced
this issue
Jul 9, 2018
added a commit
to wheatman/go-akaros
that referenced
this issue
Jul 30, 2018
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
rsc commentedSep 9, 2014
Just got with all.bash at tip: # GOMAXPROCS=2 runtime -cpu=1,2,4 --- FAIL: TestMapIterOrder-2 (0.00s) map_test.go:437: Map with n=9 elements had consistent iteration order: [0 1 2 3 4 5 6 7 8] FAIL FAIL runtime 19.833s To reproduce: go test -run MapIterOrder -cpu=$(perl -e 'print "1,"x300') -v always fails at least once. The hash function is picking the same hash bit for all 9 values (1 in 512 chance). Then instead of having two buckets we'd have one bucket plus an overflow bucket. Right now the iterator either picks a random bucket or picks a random offset within a single bucket. I think it should do both: pick a random bucket and pick a random offset, and start at that offset (and wrap) in every bucket.