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

Race condition with runfiles tree creation on Windows #12033

Open
nikhilm opened this issue Sep 1, 2020 · 0 comments
Open

Race condition with runfiles tree creation on Windows #12033

nikhilm opened this issue Sep 1, 2020 · 0 comments
Labels
area-Windows Windows-specific issues and feature requests. P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Server Issues for serverside rules included with Bazel type: bug

Comments

@nikhilm
Copy link
Contributor

nikhilm commented Sep 1, 2020

Description of the problem / feature request:

There is a race condition on Windows where Bazel can create the runfiles tree before the runfiles dependencies, leading to runfiles containing file symlinks even when the actual dependency is a directory (and a directory symlink is expected).
This manifests when running with --experimental_enable_runfiles.

This prevents reliable use of directories in runfiles trees.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Needs some custom rules, so I've created this repository, which should be usable out of the box. Please see the README in the repository for details steps to reproduce.

https://github.com/nikhilm/demo-runfiles-dir/

What operating system are you running Bazel on?

Windows 10

What's the output of bazel info release?

release 3.4.1

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

Please see the README in the repository.

benjaminp added a commit to benjaminp/bazel that referenced this issue Sep 1, 2020
…tifacts.

Windows distinguishes between symlinks to files and symlinks to directories. The
code to create symlink trees on Windows thus inspects the targets of the links
to learn what kind of symlink to make. Unfortunately, the symlinking code did
not depend on the link targets actually being created. This race could lead to
non-deterministic and non-functional symlink trees.

Fix this problem by depending on runfiles artifacts in the SymtreeTreeAction
when the host platform is Windows.

It's certainly possible to avoid this os-dependent input dependency—by using
in-memory Artifact state for the in-process implementation and extending the
runfiles manifest format to indicate target type for build-runfiles-windows—but
this commit is the most straightforward change that remediates the serious
correctness issue represented by the previous state.

This topic has a long history. When Windows runfiles trees were actually copies
of artifacts, the "symlink" action obviously had to depend on the origin
artifacts (41f4456). That code was removed in
an interregnum period where runfiles trees weren't supported at all on Windows
(0885abd). However, the dependency was not
added back when Windows symlinked runfiles trees support was finally added
(b592dbd).

Fixes bazelbuild#12033.
@oquenchil oquenchil added area-Windows Windows-specific issues and feature requests. team-Rules-Server Issues for serverside rules included with Bazel type: bug untriaged labels Sep 2, 2020
@lberki lberki added P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed untriaged labels Nov 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Windows Windows-specific issues and feature requests. P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-Server Issues for serverside rules included with Bazel type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants