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: TestSmhasherWindowed failures on linux-386-longtest builder #39352

Closed
bcmills opened this issue Jun 1, 2020 · 8 comments
Closed

runtime: TestSmhasherWindowed failures on linux-386-longtest builder #39352

bcmills opened this issue Jun 1, 2020 · 8 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Jun 1, 2020

Now that the linux-386-longtest builder is correctly running the tests in 386 mode (as of CL 234520), it seems to be shaking out some flakiness in TestSmhasherWindowed (CC @randall77):

2020-06-01T20:38:23-13bc6d4/linux-386-longtest
2020-05-29T20:56:20-6ad5f4e/linux-386-longtest

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 1, 2020
@bcmills bcmills added this to the Backlog milestone Jun 1, 2020
@randall77
Copy link
Contributor

Are we seeing this on any other 386 builder? It seems strange that it would only occur on Windows.

@randall77
Copy link
Contributor

Sorry, nevermind, it happens on linux-386-longtest also.

@bcmills
Copy link
Contributor Author

bcmills commented Jun 1, 2020

Erm, that was a typo anyway. We don't actually have a 32-bit Windows longtest builder.

@randall77 randall77 self-assigned this Jun 12, 2020
@randall77
Copy link
Contributor

I'm pretty sure we just need to raise the threshold a bit. I've investigated the collisions that happen, and they all seem to be pairwise, so they are not a big deal.
"pairwise" = when there are 32 collisions, it is two keys mapping to the same hash, 32 times, not 33 keys all mapping to the same hash.

It happens on the 386 builder because the hash results are only 32 bits. On the 64 bit builders the hash is 64 bits, which makes collisions much less likely.

@gopherbot
Copy link

Change https://golang.org/cl/237718 mentions this issue: runtime: raise alert threshold on window smhasher test

@dmitshur dmitshur modified the milestones: Backlog, Go1.15 Aug 21, 2020
@toothrot
Copy link
Contributor

toothrot commented Nov 5, 2020

This just failed on linux-386-longtest for the Go 1.14.11 release CL: https://golang.org/cl/267878

Log: https://storage.googleapis.com/go-build-log/acc740df/linux-386-longtest_b354db50.log

@randall77 should this be backported? If the threshold is being raised, should the test simply be retried for this release?

@randall77
Copy link
Contributor

You can just retry. Its failure rate is pretty low, so it didn't seem worth backporting.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants