-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/build: freebsd-arm-paulzhol builder is failing cmd/link TestDWARF #41101
Comments
@bcmills The first one is wrong (
the second
but eventually this is just passed to an os/exec.Cmd struct in the buildlet exec handler, where
I randomly sampled an active build, and only the correct (last) value is set:
Looking at the PATH above, and #31567 (comment) I don't have the bootstrap go1.4 set, or is there any other go installation present. The other difference I can think of, is my builder has the entire filesystem mounted read-only, so https://golang.org/cl/223746 is needed to ignore failing writes. Although |
There was some discussion in #43197 about this test before I closed that as a dup of this issue. cc @golang/osp-team @cherrymui @jeremyfaller @thanm |
I have a suspicion as to why this is happening, but I'm not sure how to prove it: I think there is at least one other parallel build in progress while the In the SlowBots run for https://golang.org/cl/276892 (log) captured STDOUT
I saw a build running with
Could it have forced a rebuild of the toolchain (triggering the cmd/link is stale)? |
Bump. @cherrymui @jeremyfaller @thanm, do any of you have time to look at this? It would be good for this builder to be green before the release. At least in principle the builder is more accessible now, though I waited 10 minutes for it before giving up. |
Yeah, this is still on my list. I'll do something later today. |
Thanks! Please contact me by email, I need to add a user with an authorized SSH key for you to use (the buildlet |
When building the toolchain, cmd/dist sets When running the test, the coordinator sets On gomote,
When I wonder why the coordinator sets (Perhaps the go command's staleness check can be made more resilient to this kind of equivalent but not lexically identical paths? Or maybe not worth it.) |
It's likely because earlier in Go's history it was normal/expected to set more environment variables explicitly, e.g., before GOPATH was automatic, and before That was a long time ago, but we haven't made changes to the testing strategy since then. It might be possible to stop doing it by now, if it is deemed better. |
I think that would actually be incorrect, since the lexical value of |
Another data point.
So |
Yeah, these paths are equivalent, but the go command is sensitive to the lexical path (which one is used). If stop setting GOROOT in the coordinator is not possible in the short term, another possibility is to set it consistently for build and testing, or move the work tree somewhere else that is not a symlink. |
With @bcmills 's CL https://go-review.googlesource.com/c/go/+/322629 , it is passing now (staleness check removed). I still think it is a good idea to make GOROOT and GOROOT_FINAL settings consistent for the builder. |
I've updated the nanobsd image to be based on FreeBSD 13.0 with |
https://build.golang.org/log/d0025d71cbb3628b7800d2eebe1d8fb58c79969d
I've captured the stdout/stderr output from the buildlet to look at the env. variables as I understand it was related to clearing
GOROOT_FINAL
in similar issues.Maybe this is a dup of #33598 but on FreeBSD-arm.
The text was updated successfully, but these errors were encountered: