rules_go sandboxing issue #1910
Comments
|
Just to summarize the problem reported in the sandboxfs tracker, the Go rules are putting |
|
Hmm, all of the necessary SDK files are registered as inputs (everything except the pre-compiled standard library for the host, which shouldn't be needed for cross-compilation). This works with remote execution, so I wouldn't expect missing inputs would be a problem. Is it possible GoStdLib is triggering a sandboxfs bug here? The GoStdLib action basically copies the I tried to reproduce this, but it looks like setting up sandboxfs on macOS will take more time than I have today (it requires Rust, Brew, pkg-config, osxfuse at least). |
|
I don't think this is a sandboxfs bug. This is what sandboxfs is asked to map: and Bazel doesn't do anything particularly special here: it just passes the list of inputs for an action pretty much verbatim to sandboxfs. Note that the only thing under I've also tried to pass Also, the only two actions that fail in the whole build are (I should have a release for sandboxfs out soon, which will come with prebuilt packages and thus simplify installation. But this bug concerns me slightly so I might hold off before doing that until we know what's happening.) |
|
I don't know if this is the exact solution, but this fixes the problem: diff --git a/go/private/rules/info.bzl b/go/private/rules/info.bzl
index a63426a..66c5468 100644
--- a/go/private/rules/info.bzl
+++ b/go/private/rules/info.bzl
@@ -27,7 +27,7 @@ def _go_info_impl(ctx):
args = go.builder_args(go)
args.add("-out", report)
go.actions.run(
- inputs = [go.go],
+ inputs = [go.go] + go.sdk_files,
outputs = [report],
mnemonic = "GoInfo",
executable = ctx.executable._go_info, |
|
@jayconrod Just fyi the issue can also be reproduced on Linux, imo the manual compilation is slightly "simpler" there. |
|
Hmm... that's right, the original message from @Globegitter hinted at a different issue. The patch I proposed works for me, but maybe there is some other different issue when running on Linux instead of macOS. Would be good if @Globegitter confirms. |
|
I just tried #1917 and I can build that just fine. I will also test this now on our go appplications to see if that also fixed building those. |
|
Still running into issues in building the go app I just tested, getting the following error: I will see if I can get a reproduction repo online. Edit: Actually that is also failing without sandboxfs but just with a very different error message: So maybe the failure is not due to sandboxfs as nogo disabled I can compile the app with and without sandboxfs without any problems. |
|
I was just testing another of our go apps (having nogo deactivated again), which works fine without sandboxfs but with sanboxfs I am getting the following error: This is a project using protobufs/grpc (the other one is not), but not sure if that has anything to do with the failure. Again will see if I can put up a reproduction repo. |
|
@Globegitter If you could come up with a reproduction case "soon", it'd be awesome. I want to cut a sandboxfs release but this issue makes me nervous and would like to figure out what's going on beforehand. I've just tried building a Go project that uses protobufs and couldn't reproduce though... |
|
@jmmv @jayconrod sorry for the delay here a repro repository: https://github.com/Globegitter/sandboxf-go-repro just run: Setting |
|
@jayconrod I can still reproduce the unrelated nogo error reported above on the latest commit on master on one of our apps (but have not been able to reproduce it yet with a minimal example) - should I pull this out into a separate issue? |
|
OK, I can reproduce the problems with the given test case and command line, but only on Linux. On macOS, the problems don't appear. The contents of the sandbox look reasonable to me: external/go_sdk is populated with what I'd expect from a GOROOT. @jayconrod So the question is, what does "build constraints exclude all Go files in" mean? Where are these build constraints defined? May it be that these are defined in terms of paths outside of the sandbox and, because we don't use symlinks anymore, we confuse the tool? |
|
"build constraints exclude all Go files" would be emitted by |
|
I see. So, for example, take this error: If I check the content of that directory after the action failed: and the file is readable. Should I be looking for something else that might not be there? Something else I tried is running but specifying the GOROOT as absolute works fine: so I think this is OK too. |
|
I was able to reproduce this. I spent some time debugging, but I'm afraid I wasn't able to get very far. To recap, this is basically what the action is doing (not literally this, but something similar): I confirmed that the files in The packages that are failing to build don't seem like they're intended to be built with I wonder if there's some I/O error reading the source files that the list process is running into but the compile process is not? I'm not sure if the Go command would report errors when it's just listing packages to build. |
|
Were you able to reproduce this using the shell code you posted above, with |
|
No, I couldn't reproduce it using the shell code. I just meant to provide that as an explanation in case there was anything in there that obviously wouldn't work. |
|
Looking into the sandbox directory for the real failing action: Is that |
|
|
|
Has this been fixed? There was #1917 merged but this ticket was not closed. Testing sandboxfs, not sure if it is the same issue but similar output: |
I just started to test out the new rust sandboxfs implementation and upon building one of our go applications ran into an issue. First this was an issue in sandboxfs itself, but after reporting the issue there, it seems the issue is within rules_go itself, see bazelbuild/sandboxfs#67 for the actual bug report as well as the investigation on the issue.
The text was updated successfully, but these errors were encountered: