-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
syscall: TestDirent failures with fewer than expected names #37323
Comments
2022-01-07T02:37:20-40afced/linux-riscv64-jsing |
I notice that the test has a seemingly-arbitrary If I reduce that constant to 128, I get exactly this failure mode. So I wonder if perhaps the constant is incorrect on some systems under some conditions. The “blame” layer shows that the constant comes from CL 141297 (CC @paulzhol @bradfitz @ianlancetaylor). |
This looks like an easily-fixed bug in the test, and it has failed on |
Change https://golang.org/cl/376334 mentions this issue: |
IIRC that test originated from a freebsd-only fix for parsing direntries retuned from the cooked syscall.
I think All the size calculations in that test with multiples of 4 or 8 are due to the freebsd 11/12 inode64 compatability shim which can now be removed, now that freebsd 11 is no longer supported. |
ReadDirent returns only as many directory entries as will fit in the buffer, and each entry is variable-length — so we have no guarantee in general that a buffer of a given arbitrary size can hold even one entry, let alone all ten entries expected by the test. Instead, iterate calls to ReadDirent until one of the calls returns zero entries and no error, indicating that the directory has been read to completion. Fixes golang#37323 Change-Id: I7f1cedde7666107256604e4ea1ac13c71f22151a Reviewed-on: https://go-review.googlesource.com/c/go/+/376334 Trust: Bryan Mills <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
2020-02-19T20:58:16-f08734d/linux-arm
2020-02-04T23:15:01-e3f2e9a/linux-arm
CC @randall77 @cherrymui @ianlancetaylor
The text was updated successfully, but these errors were encountered: