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

bytes/hash: TestSmhasherSmallKeys flake on android-arm-corellium builder #34834

Closed
bcmills opened this issue Oct 11, 2019 · 3 comments
Closed

bytes/hash: TestSmhasherSmallKeys flake on android-arm-corellium builder #34834

bcmills opened this issue Oct 11, 2019 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.14

Comments

@bcmills
Copy link
Contributor

bcmills commented Oct 11, 2019

From the android-arm-corellium builder (https://build.golang.org/log/6d0506edef76d21049f50f3d2a77cf686d063476):

--- FAIL: TestSmhasherSmallKeys (0.15s)
    smhasher_test.go:95: unexpected number of collisions: got=256 mean=0.000000 stddev=0.000011
FAIL
FAIL	bytes/hash	0.639s

CC @randall77
@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 11, 2019
@bcmills bcmills added this to the Go1.14 milestone Oct 11, 2019
@randall77
Copy link
Contributor

I think what is going on here is that we're getting invalid random data on startup (_AT_RANDOM content not actually random, or perhaps zero length, or no _AT_RANDOM and /dev/urandom isn't random).
I can reproduce the behavior on 386 by setting GODEBUG=cpu.all=off (to get the same hash algorithm that arm uses) and commenting out the call to getRandomData in runtime/alg.go:alginit.

We use different parts of the startup random data to make the hash length-dependent. If the startup random data is not random (all zero, probably) then the length-dependence of the hash goes away, and that's the behavior we're seeing (the 256 length 1 hashes are colliding with some of the 256^2 length 2 hashes).

@randall77
Copy link
Contributor

I guess this could happen by chance with probability ~2^-16 (top ~16 bits of two 32-bit random numbers differ by a one-bit shift).

It hasn't recurred. I'm inclined to leave this as is and see if it happens again.

@ianlancetaylor
Copy link
Contributor

It hasn't happened again. Let's close and reopen if we see it.

@golang golang locked and limited conversation to collaborators Dec 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.14
Development

No branches or pull requests
4 participants
@ianlancetaylor @bcmills @randall77 @gopherbot