runtime: TestSignalIgnoreSIGTRAP failures on openbsd #49725
Labels
help wanted
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-OpenBSD
Milestone
Comments
|
Marking as release-blocker due to the high failure rate. OpenBSD is not a first-class port and this smells to me like a kernel signal-delivery bug, so IMO this issue can be unblocked by skipping the test on this platform. |
bcmills
added
NeedsInvestigation
It looks like The failures in that issue look similar. Sending a CL to skip on all OpenBSD builders. |
|
Change https://golang.org/cl/367115 mentions this issue: |
tklauser
added
help wanted
and removed
release-blocker
okay-after-beta1
gopherbot
pushed a commit
that referenced
this issue
Dec 1, 2021
TestSignalIgnoreSIGTRAP is flaky on OpenBSD and the cause is suspected to be a kernel bug. This test is currently only skipped on the previous OpenBSD 6.2 and 6.4 builders for #17496. In the meantime the OpenBSD builders were upgraded to more recent OpenBSD versions (currently 6.8 and 7.0). It seems the issue is still present in these OpenBSD versions and there is no obvious workaround in Go. Thus, skip the flaky test on OpenBSD in general. Updates #17496 Updates #49725 Change-Id: I3577d287dcfaad7a81679db2e71540854fce065a Reviewed-on: https://go-review.googlesource.com/c/go/+/367115 Trust: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
greplogs --dashboard -md -l -e '(?ms)FAIL: TestSignalIgnore' --since=2019-11-092021-11-18T02:18:12-72f0976/openbsd-amd64-70
2021-11-17T18:14:23-9bdbed1/openbsd-386-68
2021-11-16T15:38:59-7f4a946/openbsd-386-68
2021-11-11T04:41:56-d5a5a13/openbsd-386-68
2021-11-08T22:05:00-67e2294/openbsd-386-68
2021-11-04T21:33:23-71fc881/openbsd-386-68
2021-10-04T15:50:43-9432320/openbsd-386-68
2021-09-17T22:41:29-50e4508/openbsd-arm64-jsing
2021-08-18T08:26:44-8b471db/openbsd-386-68
2021-05-26T22:43:54-1d5298d/openbsd-arm64-jsing
2021-05-26T18:33:56-a92460f/openbsd-arm64-jsing
2021-04-18T17:40:12-4efd581/openbsd-386-68
2021-03-17T07:01:00-72b501c/openbsd-arm-jsing
2021-03-15T19:02:39-2d4042d/openbsd-386-68
2021-03-12T02:21:04-7133096/openbsd-arm64-jsing
2021-02-11T18:04:49-249da7e/openbsd-arm-jsing
2020-12-01T21:41:39-7430266/openbsd-386-68
2020-10-09T13:44:17-51690f7/openbsd-arm-jsing
2020-09-05T14:11:21-bf833ea/openbsd-arm-jsing
2020-03-10T19:41:44-5db3c8f/openbsd-386-64
2020-02-20T14:58:21-24fa159/openbsd-386-62
2020-02-07T23:44:32-a6b03c6/openbsd-amd64-64
2020-02-07T18:08:01-b806182/openbsd-386-62
2019-12-06T23:44:51-94ddb2d/openbsd-386-62
It's not clear to me whether this is related to the other OpenBSD issues (CC @mknyszek @prattmic) or completely independent (CC @4a6f656c).
Given the failure rate at the fact that it seems confined to OpenBSD, perhaps we should add a skip for this test for
GOOS=="freebsd"?The text was updated successfully, but these errors were encountered: