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
Comments
Are we seeing this on any other 386 builder? It seems strange that it would only occur on Windows. |
Sorry, nevermind, it happens on linux-386-longtest also. |
Erm, that was a typo anyway. We don't actually have a 32-bit Windows longtest builder. |
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. 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. |
Change https://golang.org/cl/237718 mentions this issue: |
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? |
You can just retry. Its failure rate is pretty low, so it didn't seem worth backporting. |
Now that the
linux-386-longtest
builder is correctly running the tests in386
mode (as of CL 234520), it seems to be shaking out some flakiness inTestSmhasherWindowed
(CC @randall77):2020-06-01T20:38:23-13bc6d4/linux-386-longtest
2020-05-29T20:56:20-6ad5f4e/linux-386-longtest
The text was updated successfully, but these errors were encountered: