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
x/tools/imports: imports_test is flaky #18142
Comments
FWIW, I am unable to reproduce this with 5,000 runs on GNU/Linux amd64, both on
I tested this version of goimports: golang/tools@908849c |
I've just received a bug report in Debian because of this very issue. It seems this test fails sometimes, but I was not able to reproduce it either.. |
Sorry, I dropped the ball on this. I actually spent a fair bit of time debugging it but didn't make it far. IIRC, it seemed filesystem-specific. @TheTincho, do you know which filesystem the Debian auto-builders run on? |
@bradfitz Uhm, no.. But I'd bet it is ext4 |
The problem is that fastWalk uses multiple goroutines to walk the filesystem (one of the reasons that it's fast). fastWalk documents that it doesn't follow symlinks unless the caller requests it (per symlink). goimports does request following symlinks and tries to stop infinite walks from symlink loops, but depending on the order of goroutine scheduling, different paths can be explored through the test's created filesystem layout (which includes a symlink loop), and an unlucky rare ordering can cause the test to fail, finding the unexpected name for a path. Probably the callback's mechanism to stop infinite symlink loop walking should be changed. Some debug output of a successful run (first) vs a failure (second):
|
CL https://golang.org/cl/37947 mentions this issue. |
Building on tip on amd64 GNU/Linux.
Run
./imports.test
500 times. It failed once, with the following error:CC @bradfitz
The text was updated successfully, but these errors were encountered: