-
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
I/O exception during sandboxed execution: input dependency could not be checked for modifications during execution #15340
Comments
Looping in @frazze-jobb who wrote the hermetic sandbox code. |
Leaving out |
@frazze-jobb is on another project now. I worked with him on this sandbox and answer instead. Thanks for reporting this issue. I will try to find time to investigate this and planning to create test cases for a few related special cases. |
FYI, I'm encountering the same problem in the context of a hermtic cc_toolchain using a symlink.
Trying to build the binary via
results in
|
So the command-line output is not that useful, but looking into the server log I see this stack trace which shows a UnsupportedOperationException at FileArtifactValue.java:352 - it's trying to get a ContentsProxy of a directory, which isn't supported. Despite what FileArtifactValue may think, it's not always an actual file. So the modification check should take appropriate action on things that are not files.
|
Looking at the possible subclasses of FileArtifactValue, they mostly don't support the operations needed for the modification check. @frazze-jobb we'll have to figure out which kinds of inputs to ignore and which to handle properly. Here are the direct subclasses:
|
Thanks for looking into this. Not that it would help much, but leaving this smaller minimal example here for sake of simplicity
|
That's a nice small repro. It can also be done with just a directory as an input, so both directory and symlink handling needs to be fixed. |
The purpose of However, then the following subclasses of FileArtifactValue, mentioned by @larsrc-google, remains:
I don't see any good way to handle them. Are they rare? As workaround, should we catch UnsupportedOperationException and log a warning each time it occurs? (That could be up to one warning per action.) |
Thanks for the fix! I don't know anything about Bazel release policies - is this fix likely to make it to a 6.x release? |
@lunch-glide-pepper You can use the |
…asses Avoid exceptions from linux hermetic sandbox for unsupported FileArtifactValue subclasses. Also adds test cases to confirm no regression of existing functionality. Fixes bazelbuild#15340 Closes bazelbuild#16739. Change-Id: I0f1373f6f99328b8277fe1cec87d3946b83481c1 PiperOrigin-RevId: 490490477
…asses Avoid exceptions from linux hermetic sandbox for unsupported FileArtifactValue subclasses. Also adds test cases to confirm no regression of existing functionality. Fixes bazelbuild#15340 Closes bazelbuild#16739. Change-Id: I0f1373f6f99328b8277fe1cec87d3946b83481c1 PiperOrigin-RevId: 490490477
…asses (#16830) Avoid exceptions from linux hermetic sandbox for unsupported FileArtifactValue subclasses. Also adds test cases to confirm no regression of existing functionality. Fixes #15340 Closes #16739. Change-Id: I0f1373f6f99328b8277fe1cec87d3946b83481c1 PiperOrigin-RevId: 490490477 Co-authored-by: Ulrik Falklof <[email protected]> Co-authored-by: kshyanashree <[email protected]>
Description of the bug:
My build fails with
I/O exception during sandboxed execution: input dependency <path> could not be checked for modifications during execution
. The error seems to be about a symlink inside a tree artifact, with the symlink pointing to a directory inside the same tree artifact, and only happens when using--experimental_use_hermetic_linux_sandbox
.Using bazel 5.1.1 (official binaries), and also reproduced with recent master at 4e6153e, on Ubuntu 20.04.
Simplified reproduction below.
I'm sure that I'm doing a number of questionable things that can be achieved in better ways, but the error looks more like a bug than a deliberate error message, so I figured I'd open an issue.
Output:
Workaround that makes the build work (and also works in the real codebase that this example is derived from), but I have no idea what this actually does (based on 4e6153e):
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
No response
What is the output of
bazel info release
?No response
If
bazel info release
returnsdevelopment version
or(@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
?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: