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

Fix JacocoInstrumentationProcessor move() failure on some filesystems #25273

Closed
wants to merge 1 commit into from

Conversation

dmivankov
Copy link
Contributor

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 #25272

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
@dmivankov dmivankov requested a review from a team as a code owner February 13, 2025 14:16
@github-actions github-actions bot added team-Rules-Java Issues for Java rules awaiting-review PR is awaiting review from an assigned reviewer labels Feb 13, 2025
@dmivankov
Copy link
Contributor Author

Haven't yet run the patch on repro case, but will do

@dmivankov
Copy link
Contributor Author

Needs a java_tools bump somewhere, bazel build src:bazel_nojdk doesn't even compile this class

@dmivankov
Copy link
Contributor Author

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 javabuilder = ":JavaBuilder_deploy.jar",

@fmeum
Copy link
Collaborator

fmeum commented Feb 13, 2025

This probably also fixes #24838.

@dmivankov
Copy link
Contributor Author

Validated that the fix works via dmivankov/bug_reports@04cb53e

@hvadehra hvadehra requested a review from c-mita February 14, 2025 08:39
Copy link
Member

@c-mita c-mita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks

@c-mita c-mita added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Feb 14, 2025
@EdSchouten
Copy link
Contributor

Thank you for making fixes to improve compatibility with Buildbarn’s FUSE file system. Really appreciated!

@github-actions github-actions bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
coverage team-Rules-Java Issues for Java rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Coverage doesn't work for JVM targets with buildbarn FUSE workers
5 participants