Skip to content
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

os: nonzero exit status mishandled on OpenBSD before 009_exit syspatch #42542

Closed
bcmills opened this issue Nov 12, 2020 · 13 comments
Closed

os: nonzero exit status mishandled on OpenBSD before 009_exit syspatch #42542

bcmills opened this issue Nov 12, 2020 · 13 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-OpenBSD
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Nov 12, 2020

cmd/go calls os.Exit with a nonzero status code on failure:

os.Exit(exitStatus)

The cmd/go tests use os/exec to execute subprocesses, and check them for the expected exit status:

waitErr := cmd.Wait()

Tests that expect nonzero exit status are failing frequently on the openbsd-arm64-jsing builder (CC @4a6f656c), which suggests that either os.Exit is not consistently causing the process to exit with the correct status, or (*os.Process).Wait is not consistently reporting the correct status.

It is not clear to me whether this is a bug in the Go standard library or the OpenBSD kernel.

2020-11-12T10:22:50-d7974c3/openbsd-arm64-jsing
2020-11-11T20:51:00-141fa33/openbsd-arm64-jsing
2020-11-10T18:03:53-1948c00/openbsd-arm64-jsing
2020-11-10T04:11:42-1642cd7/openbsd-arm64-jsing
2020-11-09T21:36:24-d361691/openbsd-arm64-jsing
2020-11-09T21:03:36-d495712/openbsd-arm64-jsing
2020-11-09T19:00:00-01cdd36/openbsd-arm64-jsing
2020-11-09T17:38:50-a6462a6/openbsd-arm64-jsing
2020-11-09T13:12:41-2231243/openbsd-arm64-jsing
2020-11-07T16:59:55-5e371e0/openbsd-arm64-jsing
2020-11-07T03:52:47-d51ae66/openbsd-arm64-jsing
2020-11-06T19:42:05-362d25f/openbsd-arm64-jsing
2020-11-06T15:33:23-d21af00/openbsd-arm64-jsing
2020-11-05T23:21:33-ecc3f51/openbsd-arm64-jsing
2020-11-05T22:14:40-8e5778e/openbsd-arm64-jsing
2020-11-05T17:52:17-06538fa/openbsd-arm64-jsing
2020-11-05T16:47:45-a19a4dc/openbsd-arm64-jsing
2020-11-05T16:47:18-0c86172/openbsd-arm64-jsing
2020-11-05T16:46:56-04b5b4f/openbsd-arm64-jsing
2020-11-05T16:43:34-40f0359/openbsd-arm64-jsing
2020-11-05T16:20:01-8ab8125/openbsd-arm64-jsing
2020-11-05T14:54:35-74ec40f/openbsd-arm64-jsing
2020-11-05T10:46:08-3510a1e/openbsd-arm64-jsing
2020-11-05T02:28:14-1e3b535/openbsd-arm64-jsing
2020-11-05T00:21:39-c018eec/openbsd-arm64-jsing
2020-11-04T21:02:29-e4b4e4b/openbsd-arm64-jsing
2020-11-03T23:05:51-e1b305a/openbsd-arm64-jsing
2020-11-03T21:43:30-da7aa86/openbsd-arm64-jsing
2020-11-03T01:27:45-cc0930c/openbsd-arm64-jsing
2020-11-02T21:10:41-ac766e3/openbsd-arm64-jsing
2020-11-02T21:08:14-4fcb506/openbsd-arm64-jsing
2020-11-02T15:41:00-33d9251/openbsd-arm64-jsing
2020-11-02T15:40:28-202aa08/openbsd-arm64-jsing
2020-10-31T00:17:28-07e4f0f/openbsd-arm64-jsing
2020-10-30T21:14:09-f96b62b/openbsd-arm64-jsing
2020-10-29T19:06:32-5cc43c5/openbsd-arm64-jsing
2020-10-29T01:50:09-308ec22/openbsd-arm64-jsing
2020-10-28T19:19:18-1090f09/openbsd-arm64-jsing
2020-10-28T17:10:08-642329f/openbsd-arm64-jsing
2020-10-28T05:02:44-150d244/openbsd-arm64-jsing
2020-10-17T19:22:49-30119bc/openbsd-arm64-jsing

@bcmills bcmills added OS-OpenBSD NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-arm64 labels Nov 12, 2020
@bcmills bcmills added this to the Backlog milestone Nov 12, 2020
@bcmills
Copy link
Contributor Author

bcmills commented Nov 12, 2020

@golang/release, you might consider marking this builder with a KnownIssue until this is resolved. Based on the status of #31656, it appears that this port is incomplete and not yet supported.

@4a6f656c
Copy link
Contributor

@golang/release, you might consider marking this builder with a KnownIssue until this is resolved. Based on the status of #31656, it appears that this port is incomplete and not yet supported.

FWIW the port is complete (has been for a long time) - the only reason it is not yet supported was due to the lack of a builder, which has now been addressed.

Re this specific issue, the failures are all TestScript... a couple of interesting things to note - firstly, this seems to have started when the builder was upgraded and some of the binaries were not (which I've just fixed). Having said that, I'm pretty sure that some of the TestScript tests are relying on the local Go binary (/usr/local/go/bin/go in this case), rather than the Go binary that has been built from source (probably not what we want):

$ kdump -HT | grep NAMI | grep bin/go 
 28299/455478  go.test  1605204346.818164 NAMI  "/usr/local/go/bin/go"
 29314/257479  go.test  1605204346.830077 NAMI  "/usr/local/go/bin/go"
 29314/257479  go       1605204346.875199 NAMI  "/usr/local/go/bin/go"
 53698/463669  go.test  1605204346.973705 NAMI  "/usr/local/go/bin/go"
 98216/426375  go.test  1605204347.116089 NAMI  "/usr/local/go/bin/go"
 59520/594260  go.test  1605204347.253691 NAMI  "/usr/local/go/bin/go"
...
 | | |-+= 60121 joel ./go.test -test.run=TestScript
 | | | |-+- 72510 joel /tmp/cmd-go-test-091599085/tmpdir936823144/testbin/go test -v multimain
 | | | | \--- 01312 joel (vet)
 | | | |-+- 26114 joel /tmp/cmd-go-test-091599085/tmpdir936823144/testbin/go build rsc.io/CGO
 | | | | \--- 51018 joel cc -I /tmp/cmd-go-test-091599085/tmpdir936823144/script-mod_case_cgo/gopath/pkg/mod/rsc.io/!c!g!o@v1.0.0 -fPIC -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/t
 | | | |--- 59076 joel /tmp/cmd-go-test-091599085/tmpdir936823144/testbin/go vet m/onlycgo
 | | | \-+- 30712 joel /tmp/cmd-go-test-091599085/tmpdir936823144/testbin/go install main_test
 | | |   \--- 38529 joel /usr/local/go/pkg/tool/openbsd_arm64/link -o /tmp/cmd-go-test-091599085/tmpdir936823144/script-test_main_archive/tmp/go-build539908792/b001/exe/a.out -importcfg /tmp/cmd-go-test-091599085/tmpdir93682314

If my suspicion is correct, this will clear as the next builds occur.

@4a6f656c
Copy link
Contributor

Interesting - the OpenBSD 6.8 openbsd/386 and openbsd/amd64 new builders are showing the same symptoms, so this is presumably not openbsd/arm64 specific.

@dmitshur dmitshur changed the title os: nonzero exit status mishandled on openbsd/arm64 os: nonzero exit status mishandled on OpenBSD Nov 13, 2020
@4a6f656c
Copy link
Contributor

I've confirmed that this is an issue with the OpenBSD kernel - a fix has been manually applied to the openbsd/arm64 builder and I'm hoping that a syspatch can be made available for it soon.

@4a6f656c
Copy link
Contributor

@dmitshur OpenBSD have released an errata for this issue - this should be picked up via syspatch if the OpenBSD 6.8 builder images are recreated.

@dmitshur
Copy link
Contributor

@4a6f656c Thank you for letting me know. I'll create new versions of the openbsd-amd64-68 and openbsd-386-68 images, and post an update in #35712.

@gopherbot
Copy link

Change https://golang.org/cl/277115 mentions this issue: dashboard: update OpenBSD 6.8 images with 009_exit syspatch

gopherbot pushed a commit to golang/build that referenced this issue Dec 11, 2020
For golang/go#35712.
Updates golang/go#42542.
Updates golang/go#42426.

Change-Id: Ifbdd025b8d1708e715ba312c438f391e1aeaeff8
Reviewed-on: https://go-review.googlesource.com/c/build/+/277115
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
@gopherbot
Copy link

Change https://golang.org/cl/278732 mentions this issue: env/openbsd-amd64: syspatch on first boot

gopherbot pushed a commit to golang/build that referenced this issue Dec 17, 2020
syspatch is currently being invoked at the end of the installation, which
means we're trying to patch the installation ramdisk kernel, rather than the
generic kernel. Instead, invoke syspatch during the first boot of the generic
kernel. Move pkg_add as well, since that is also generally safer to run outside
of the installation.

Update golang/go#35712
Update golang/go#42542

Change-Id: Icbb384816de5859078a0183919626d223fb0060f
Reviewed-on: https://go-review.googlesource.com/c/build/+/278732
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/279134 mentions this issue: dashboard: update OpenBSD 6.8 images with 009_exit syspatch, take 2

gopherbot pushed a commit to golang/build that referenced this issue Dec 18, 2020
These images were regenerated after the fix in CL 278732.

For golang/go#35712.
Updates golang/go#42542.
Updates golang/go#42426.

Change-Id: Ib9c9dc316e4f68e7fed2cafe5400942a94ba8fd2
Reviewed-on: https://go-review.googlesource.com/c/build/+/279134
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
@gopherbot
Copy link

Change https://golang.org/cl/279512 mentions this issue: dashboard: promote OpenBSD 6.8 builders to be default

@dmitshur
Copy link
Contributor

dmitshur commented Dec 22, 2020

I understand this was determined to be an issue in the OpenBSD kernel, which should be resolved via the 009_exit syspatch. Can this issue be closed, or is there more left to do here?

gopherbot pushed a commit to golang/build that referenced this issue Dec 23, 2020
The known issue with OpenBSD 6.8 builders appears to be resolved
via CL 278732 and CL 279134. Promote them to the primary OpenBSD
post-submit builders and TryBots.

Having test coverage from OpenBSD 6.8 and 6.4 builders gives us
us more confidence that Go works on supported OpenBSD versions
(which are 6.8 and 6.7 at this time, per past policy decision
in https://golang.org/issue/15227#issuecomment-293319876).

Reduce numTryTestHelpers from 5 to 4 based on some data from
golang.org/issue/37439 showing that going from 3 to 5 helpers
doesn't make a significant difference. We can adjust further
if we learn that OpenBSD TryBots become the bottleneck.

Fixes golang/go#35712.
For golang/go#42542.
For golang/go#42064.
Updates golang/go#42426.

Change-Id: Id2fa4be7c3161f89752c1428146846fe06ca63db
Reviewed-on: https://go-review.googlesource.com/c/build/+/279512
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
@dmitshur dmitshur changed the title os: nonzero exit status mishandled on OpenBSD os: nonzero exit status mishandled on OpenBSD before 009_exit syspatch Jan 20, 2021
@4a6f656c
Copy link
Contributor

I understand this was determined to be an issue in the OpenBSD kernel, which should be resolved via the 009_exit syspatch. Can this issue be closed, or is there more left to do here?

@dmitshur - correct, as far as I'm concerned this can be closed.

@dmitshur
Copy link
Contributor

Thank you for your work on this Joel, and Bryan for catching and reporting the issue.

@golang golang locked and limited conversation to collaborators Jan 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-OpenBSD
Projects
None yet
Development

No branches or pull requests

4 participants