x/build: plan9-386 builder fails #29801
Assignees
Labels
Builders
x/build issues (builders, bots, dashboards)
help wanted
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Plan9
Milestone
Comments
bradfitz
added
help wanted
OS-Plan9
NeedsInvestigation
|
Change https://golang.org/cl/158537 mentions this issue: |
gopherbot
pushed a commit
to golang/build
that referenced
this issue
Jan 18, 2019
Updates golang/go#29801 Change-Id: Ib346d717ae9b8de18666d6ea543d9bdcd2856f3b Reviewed-on: https://go-review.googlesource.com/c/158537 Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
I'm not sure if it's related to this issue, or a separate issue, but there haven't been any plan9 builder results for any of the subrepos recently. I.e., https://build.golang.org/?repo=golang.org%2fx%2ftools has no entries for |
|
Yes, there is currently an issue happening on the plan9/386 builder. It started on 2019-02-01 approximately. I'll investigate. |
|
What's the status here? I haven't seen a plan9/386 build pass in a long time. |
|
I'm currently investigating an issue with the runtime/trace test running out of memory on the plan9/amd64 builder. The issue on the plan9/386 builder is different. I've not been able to reproduce it yet, since it runs successfully on my 386 machines at home. I'll have to try on GCE. There was something very odd on the plan9/386 builder during the past few months. The builder started to fail in early February, then after 4 weeks of failure, the tests passed successfully in early March during 8 days, then it started to fail again. |
|
I'm going to have to stop the plan9 builders. It's a waste of resources & distracting to have them always building and resulting in crashes, loops, timeouts, or other failures. |
|
Could you try to disable the runtime/trace tests? It may be the same issue I'm currently encountering on plan9/amd64. |
|
After a few more tests, it seems unlikely that the issue may be caused by the runtime/trace test. I'm suspecting something else. Please hang on. |
|
I ran |
|
The builders don't run all.rc or all.bash, etc. They run make.ext and then use go tool dist test to run the tests. Maybe something's broken with Plan 9's subprocess handling. |
|
Change https://golang.org/cl/172797 mentions this issue: |
|
Could you give me a builder key so I could run the plan9/386 buildlet on my side and debug it? |
|
You can use the buildlet & debugnewvm (perhaps modified) to test it. |
gopherbot
pushed a commit
to golang/build
that referenced
this issue
Apr 18, 2019
It hasn't passed in months and now spins, wasting resources. Updates golang/go#31261 Updates golang/go#29801 Change-Id: Idcf13ae915bad4febb156c5c5d49f07f76cf9d49 Reviewed-on: https://go-review.googlesource.com/c/build/+/172797 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
I figured how to use debugnewvm, then ran the plan9/386 build. The tests passed successfully, except the issue30908 test (issue #31503). Now, I'm puzzled. |
|
I ran the plan9/386 build in I am using:
|
|
debugnewvm doesn't quite do what the coordinator does, either. It's much closer and is useful for debugging, but it's not 100% the same (yet?). It still runs all.rc instead of running each test separately. I wonder if that's related. I can't think of anything else. |
|
I'm unfamiliar with the coordinator internals. How difficult would it be to change debugnewvm to run the tests separately and behave closer to the coordinator? |
|
@bradfitz Would it be possible to send me a builder key for another plan9/386 builder, so I could run the buildlet on my side? |
|
@0intro, sure, send a CL to dashboard/builders.go adding the new host type & builder ( |
|
Change https://golang.org/cl/175901 mentions this issue: |
gopherbot
pushed a commit
to golang/build
that referenced
this issue
May 9, 2019
This change adds the plan9-386-0intro builder configuration. Updates golang/go#29801. Change-Id: I5f64f4592a499eb1691498805fd0dfa5082c33d5 Reviewed-on: https://go-review.googlesource.com/c/build/+/175901 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Change https://go.dev/cl/408698 mentions this issue: |
gopherbot
pushed a commit
to golang/build
that referenced
this issue
May 26, 2022
…9-amd64-0intro For golang/go#52653. Updates golang/go#29801. Updates golang/go#49756. Updates golang/go#50137. Change-Id: Ided04da5c1e403c4a194c8c645c5179534a00907 Reviewed-on: https://go-review.googlesource.com/c/build/+/408698 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Alex Rakoczy <alex@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com>
|
@golang/release I propose we try to re-enable the plan9/386 builder on GCE. I will be able to provide:
|
dmitshur
added
NeedsDecision
|
I think we're waiting for #53383 to be resolved so we have some level of clarity on secondary ports. |
dmitshur
added
NeedsInvestigation
That proposal has been accepted, and to my knowledge the |
|
We can spend some time giving it a shot. Ideally we would get a script we can use to create the image but we can settle for something that works for the moment. |
|
Here are:
I will submit a change to update the make.bash script, to take into account the update of the Plan 9 ISO image from 2018-11-30 to 2022-08-08. |
|
I have some time to work on this today. Ideally I'd like to produce the image, buildlet, and bootstrap myself; did you do anything special? |
|
It looks like the bootstrap archive and buildlet were rebuilt when we bumped the bootstrap version requirement to 1.17. I'll try to use those versions. |
To produce the image, you just have to run make.bash after updating the ISO image date. You also have to update the SHA1 file. To produce the buildlet and bootstrap, I'm running personal scripts to cross-compile them automatically from Linux. I can share them if you want. |
It should work, but beware they seem a bit old. My latest builds are the most up-to-date. |
|
This is a very, very slow builder -- it's been running for over an hour now and it's not done. Is there something that can be done to speed it up? I'm not sure we want to spend our GCE quota on this. |
|
The disk I/O are very slow on GCE, especially on Plan 9. You should make sure the build (and GOCACHE) is done inside /tmp, which is served by the ramfs (in-memory) file system. |
|
According to the comments in the buildlet, that's true by default. Any other ideas? It looks like there's an attempt to skip the |
|
Yes, we are currently skipping the |
|
I see. |
This was referenced Mar 16, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@0intro, what's doing on here?
/cc @bcmills @dmitshur
The text was updated successfully, but these errors were encountered: