"I/O exception during sandboxed execution" "Directory not empty" with --experimental_reuse_sandbox_directories
#19935
Assignees
Labels
P1
I'll work on this now. (Assignee required)
team-Local-Exec
Issues and PRs for the Execution (Local) team
type: bug
Comments
|
This reproduces with 7.0.0-pre.20231011.2. |
Pavank1992
added
the
team-Core
|
We've also been hitting this with 6.4.0 |
oquenchil
added
P1
|
I thought this was related to d6c79db but it's more likely to be unrelated. Could you please try to reproduce with Bazel head? |
|
I'm more convinced now that this is a separate bug not fixed by that PR but I will need to investigate further. |
|
@bazel-io fork 7.0.0 |
bazel-io
pushed a commit
to bazel-io/bazel
that referenced
this issue
Oct 26, 2023
bazelbuild#19935 gives a clear repro. The problem appears when a stashed sandbox contains a directory whose same path is a regular file in a later execution. If we try to reuse the stashed sandbox we trigger an error if the old directory contained any files. This was due to simply calling delete() without checking first if it was a directory. The fix is to call deleteTree() instead in those cases. directory. Fixes bazelbuild#19935 RELNOTES:none PiperOrigin-RevId: 576889004 Change-Id: I73b145cd574b83c473ffaccd90b675eb5f086c0e
iancha1992
pushed a commit
that referenced
this issue
Oct 30, 2023
…ty" with `--experimental_reuse_sandbox_directories` (#19959) #19935 gives a clear repro. The problem appears when a stashed sandbox contains a directory whose same path is a regular file in a later execution. If we try to reuse the stashed sandbox we trigger an error if the old directory contained any files. This was due to simply calling delete() without checking first if it was a directory. The fix is to call deleteTree() instead in those cases. directory. Fixes #19935 RELNOTES:none Commit 7d87996 PiperOrigin-RevId: 576889004 Change-Id: I73b145cd574b83c473ffaccd90b675eb5f086c0e Co-authored-by: Googler <[email protected]>
|
A fix for this issue has been included in Bazel 7.0.0 RC5. Please test out the release candidate and report any issues as soon as possible. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the bug:
--experimental_reuse_sandbox_directoriescan produce non-hermetic behavior when attempting to reuse a sandbox stash that contains a directory where a file is needed.Which category does this issue belong to?
Core
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Minimal example: https://github.com/jfirebaugh/bazel_experimental_reuse_sandbox_directories_bug
Clone this repository, and run
bazel build --repo_env=CREATE_DIRECTORY=1 --experimental_reuse_sandbox_directories genrulefollowed bybazel build --repo_env=CREATE_DIRECTORY=0 --experimental_reuse_sandbox_directories genrule(the only difference between the two is theCREATE_DIRECTORYvalue). The second command will fail with:If the second command is modified to remove the use of
--experimental_reuse_sandbox_directories, then it succeeds. It also succeeds if you delete the sandbox stash (rm -rf "$(bazel info output_base)/sandbox/sandbox_stash").Which operating system are you running Bazel on?
macOS
What is the output of
bazel info release?release 6.4.0
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No
Have you found anything relevant by searching the web?
No
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: