runtime: TestPreemptionAfterSyscall is flaky on Plan 9 #41015
Comments
bcmills
added
NeedsInvestigation
|
CC @aclements; this may relate to #36365. |
|
This affects multiple platforms, including (CC @jeremyfaller for routing.) |
|
Curiously, the Depending on how important this test is, it could perhaps be resolved (or at least reduced back to the backlog) by skipping on those specific builders. |
|
@cherrymui observed that the Windows failures are all just slightly over the 3 second timeout, so I think the best course here is to up the timeout slightly and skip the test on plan9. |
|
Change https://golang.org/cl/379214 mentions this issue: |
aclements
changed the title
This test occasionally takes very slightly longer than the 3 second timeout on slow builders (especially windows-386-2008), so increase the timeout to 5 seconds. It fails with much longer timeouts on Plan 9, so skip it as flaky there. Updates #41015. Change-Id: I426a7adfae92c18a0f8a223dd92762b0b91565e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/379214 Trust: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
|
The slightly higher timeout should fix this on most platforms. This bug now tracks the test skip on Plan 9 and, as such, is no longer a release blocker. |
This test occasionally takes very slightly longer than the 3 second timeout on slow builders (especially windows-386-2008), so increase the timeout to 5 seconds. It fails with much longer timeouts on Plan 9, so skip it as flaky there. Updates golang#41015. Change-Id: I426a7adfae92c18a0f8a223dd92762b0b91565e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/379214 Trust: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2020-08-24T16:53:02-fb5c3ea/plan9-386-0intro
2020-08-20T15:14:12-c57c021/plan9-386-0intro
2020-08-15T05:58:24-c0dded0/plan9-386-0intro
Also https://storage.googleapis.com/go-build-log/8d475a42/windows-386-2008_02320057.log; see previously #34901.
The text was updated successfully, but these errors were encountered: