-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Fix JacocoInstrumentationProcessor move() failure on some filesystems #25273
Conversation
Recursive directory traversal has no guarantees around files&directories that are added after the traversal has started, in particular it's unsafe to - move `.class` away to `.class.uninstrumented` - create new `.class` with same name - continue recursive traversal As it is allowed by POSIX `readdir()` to visit newly-created `.class` again https://pubs.opengroup.org/onlinepubs/007904875/functions/readdir_r.html > If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir_r() returns an entry for that file is unspecified. And second visit will attempt to instrument already instrumented `.class`, but actually fail on the `move()` step as destination already exists. This does reliably happen on buildbarn remote FUSE workers when running `bazel coverage` for JVM targets Fixes bazelbuild#25272
Haven't yet run the patch on repro case, but will do |
Needs a java_tools bump somewhere, |
Looks like the flow is: change code here -> release java_tools -> release rules_java -> update rules_java. Or maybe override java_toolchain to point to manually built |
This probably also fixes #24838. |
Validated that the fix works via dmivankov/bug_reports@04cb53e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks
Thank you for making fixes to improve compatibility with Buildbarn’s FUSE file system. Really appreciated! |
Recursive directory traversal has no guarantees around files&directories that are added after the traversal has started, in particular it's unsafe to
.class
away to.class.uninstrumented
.class
with same nameAs it is allowed by POSIX
readdir()
to visit newly-created.class
again https://pubs.opengroup.org/onlinepubs/007904875/functions/readdir_r.htmlAnd second visit will attempt to instrument already instrumented
.class
, but actually fail on themove()
step as destination already exists.This does reliably happen on buildbarn remote FUSE workers when running
bazel coverage
for JVM targetsFixes #25272