Go: os: nonzero exit status mishandled on OpenBSD

Created on 12 Nov 2020 · 9Comments · Source: golang/go

cmd/go calls os.Exit with a nonzero status code on failure:
https://github.com/golang/go/blob/0e953add9656c32a788e06438cd7b533e968b7f8/src/cmd/go/internal/base/base.go#L102

The cmd/go tests use os/exec to execute subprocesses, and check them for the expected exit status:
https://github.com/golang/go/blob/e75aef80ca3722684e707502c424c0fb28e8b1cc/src/cmd/go/script_test.go#L1183

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.

NeedsInvestigation OS-OpenBSD

Source

bcmills

Most helpful comment

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 on 16 Nov 2020

👍2

All 9 comments

@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.

bcmills on 12 Nov 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.

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/[email protected] -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 on 12 Nov 2020

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.

4a6f656c on 13 Nov 2020

👍2

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 on 16 Nov 2020

👍2

@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.

4a6f656c on 10 Dec 2020

🎉1

@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.