-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
test: issue46234.go failures with "command exceeded time limit" #50973
Comments
Thanks Brian. Happy to move this test somewhere else (ex: somewhere in the package tests for cmd/compile) if that would help. |
I don't think moving the test would particularly help, since it already doesn't run as part of (The tests in |
Change https://golang.org/cl/382774 mentions this issue: |
Change run.go to apply the GO_TEST_TIMEOUT_SCALE scaling factor to test timeouts (mentioned in "-t" clause in test header). Also with this patch, bump up the timeout for fixedbugs/issue46234.go from 30 to 45 seconds, to avoid flakes on very slow builders. Updates #50973. Change-Id: Icbafa482860e24cc1e72fee53511bcc764d06bf1 Reviewed-on: https://go-review.googlesource.com/c/go/+/382774 Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Unfortunately the
2022-03-17T08:43:15-599d539/aix-ppc64 |
|
greplogs --dashboard -md -l -e 'command exceeded time limit' --since=2021-01-01
2022-02-01T18:15:07-125c5a3/solaris-amd64-oraclerel
2021-07-01T17:07:36-eb437ba/linux-riscv64-jsing
This test was added in CL 320913 for #46234 (CC @thanm @cherrymui @mdempsky). The test runs with an apparently-arbitrary timeout to “[e]nsure that runtime traceback does not infinite loop”, but a 30-second timeout is decidedly shorter than infinity, especially when an entire program must be compiled and linked. 😅
As far as I can tell, there are only two tests that use
buildrun -t
today:issue46234.go
andissue10958.go
. And of those, the latter is disabled by default.A good first step might be to separate the “build” and “run” steps in
buildrun -t
, so that the timeout only applies to the "run" portion rather than also the “build”. Or, perhaps we should increase the timeout, and probably also applyGO_TEST_TIMEOUT_SCALE
from the builder environment.If the timeouts persist, we should probably consider terminating the program with a more appropriate signal (#50436) to obtain a core dump for investigation.
The text was updated successfully, but these errors were encountered: