-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: "unexpected stale targets" on darwin builders #33598
Comments
|
|
Not clear to me whether this is during toolchain3, or if the underlying cause is even related, but there is a similar symptom on the |
I see the same type of failure with the stale targets when I try to force -pie to be the default build mode for ppc64le (due to a request). It is noted in #28531. Maybe something wrong with the way that internal/cpu is hashed so that it doesn't get consistent results? |
@laboger, the |
Curiously, the only builder that has failed in this way in the last month or so is the (There hasn't been another 2020-03-02T17:40:11-a2bff7c/plan9-arm |
Curiously, CL 223755 seems to demonstrate that the
|
Change https://golang.org/cl/223925 mentions this issue: |
I haven't seen the |
The affected builders seem to be:
Curiously, |
(Those builders broke due to unexpected staleness in CL 223746.) |
This could be related to #35459 /cc @cagedmantis |
Some of the darwin-amd64 builders are providing a stale environment. Let's un-break them while we investigate. Updates #37573 Updates #33598 Change-Id: I8b79778fe4d5aa916557c1ba89fa9c776d130b01 Reviewed-on: https://go-review.googlesource.com/c/go/+/223925 Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Andrew Bonventre <[email protected]> Reviewed-by: Jay Conrod <[email protected]>
Change https://golang.org/cl/353352 mentions this issue: |
I think the change in CL 353549 most relevant to the issue in #33598 (comment) is in x/build/cmd/buildlet that runs on builders. Builders are generally configured with a "stage0" that's responsible for updating the buildlet binary whenever a new one becomes uploaded, so we should see results after we do so. |
Also consistently deduplicate Env entries, mainly to reduce confusion when reading logs. This change is probably larger than what is strictly needed to fix the issue, but it seemed simpler than trying to figure out which of the many calls to exec.Command in the module are actually relevant. (It also provides some useful case studies for possible additions to the Go standard library.) For golang/go#33598 Change-Id: Ia2bce4549e4a71b56fb497e3df093f79fbcf7f29 Reviewed-on: https://go-review.googlesource.com/c/build/+/353549 Trust: Bryan C. Mills <[email protected]> Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
The buildlet binary for darwin-amd64 has been updated (the rest to follow). |
Change https://golang.org/cl/354752 mentions this issue: |
In CL 353549 I refactored environment-handling in the buildlet such that an explicit per-host GOROOT_BOOTSTRAP environment configured in dashboard/builders.go overrides the latent GOROOT_BOOTSTRAP value on the host. (The entry in dashboard/builders.go may omit GOROOT_BOOTSTRAP entirely to defer to the host environment.) That change caught out a previously-unnoticed configuration mismatch for the host-ios-arm64-corellium-ios builder: its entry in dashboard/builders.go indicated "GOROOT_BOOTSTRAP=/var/mobile/go-ios-arm64-bootstrap", but (as shown in previous builder logs¹) it was actually using "GOROOT_BOOTSTRAP=/var/root/go-ios-arm64-bootstrap". The latter empirically exists on the builder, while the former does not. ¹https://build.golang.org/log/4da918256e30f3442be7885019dc2d17bc718e0d For golang/go#33598. Change-Id: I09e5f83b46f23d5a4744c752fb66fcd4b33e4cff Reviewed-on: https://go-review.googlesource.com/c/build/+/354752 Trust: Bryan C. Mills <[email protected]> Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Delightful! CL 353549 does seem to have done the trick. We could submit CL 223755 to prevent future regressions, but if I understand correctly it might seriously degrade the performance of certain builders (notably plan9). It was very useful for debugging but I'm indifferent as to whether we actually merge it. |
…clude C files This reverts CL 351851, which itself reverted CL 348991. The problem with the original CL, as far as I can tell, was due to a bug in the Go project's builder infrastructure (#33598) and not the change itself. Once the build infrastructure is fixed, this change can be resubmitted. Fixes #48319 Updates #33598 Change-Id: I0fdbcc241eb2bdeb350944aad58bf58774fb591e Reviewed-on: https://go-review.googlesource.com/c/go/+/353352 Trust: Bryan C. Mills <[email protected]> Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Jay Conrod <[email protected]>
This should be a no-op, but if the sharded builders are for some reason distributing stale snapshots — or testing them with mismatched environments — this should catch them out at a relatively low cost (#24300 notwithstanding). Given the frequently at which (*tester).runPending already checks for staleness, we do not expect the impact of this extra check to be significant for most builders. For #33598 Updates #24300 Change-Id: I197d6a69c72e2eec9e4563b459206de76c89e8a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/223755 Trust: Bryan C. Mills <[email protected]> Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Change https://go.dev/cl/407881 mentions this issue: |
… a command in a different directory Fixes #52995 Updates #33598 Change-Id: If0de906ffa2fcc83bb2a90f9e80a5b29d7667398 Reviewed-on: https://go-review.googlesource.com/c/go/+/353449 Trust: Bryan C. Mills <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> (cherry picked from commit c035d82) Reviewed-on: https://go-review.googlesource.com/c/go/+/407881 Reviewed-by: Heschi Kreinick <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Change https://go.dev/cl/367896 mentions this issue: |
For golang/go#53957. Updates golang/go#33598. Change-Id: Ie2c47dc0dfd82614b70c983f11462b70bd0703d2 Reviewed-on: https://go-review.googlesource.com/c/build/+/367896 Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Bryan Mills <[email protected]>
Two flakes in the
darwin-amd64-10_11
builders over the past week or so, both with the same symptom:unexpected stale targets
failures forinternal/cpu
, and abuild ID mismatch
forruntime/internal/sys
.CC @jayconrod @ianlancetaylor @aclements
The text was updated successfully, but these errors were encountered: