You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we introduced and changed the default GOTRACEBACK to "single" (see #13107), test time outs no longer print the traceabck of the goroutine actually running the test, or of any other goroutines that may be involved in the test being stuck or slow. This makes it difficult to debug these time outs.
panic: test timed out after 5m0s
goroutine 207854 [running]:
testing.startAlarm.func1()
/tmp/workdir/go/src/testing/testing.go:717 +0x132
created by time.goFunc
/tmp/workdir/go/src/time/sleep.go:129 +0x3a
FAIL runtime 300.006s
Unfortunately, there seems not to be a way for startAlarm to tell the system to print all stacks on panic. "go test" could pass a higher GOTRACEBACK if GOTRACEBACK isn't set (suggested by @davecheney in #13107 (comment)), but this would affect all test panics (not necessarily a bad thing), and wouldn't help if the test binary was being run directly. Another possibility is that startAlarm could print the stacks itself using runtime.Stack (with "all" set to true) and then simply exit.
The text was updated successfully, but these errors were encountered:
Since we introduced and changed the default GOTRACEBACK to "single" (see #13107), test time outs no longer print the traceabck of the goroutine actually running the test, or of any other goroutines that may be involved in the test being stuck or slow. This makes it difficult to debug these time outs.
For example, in http://build.golang.org/log/a7048d0c840f1815694b38306ce9e7f723d4e382, the runtime test times out with just
Unfortunately, there seems not to be a way for startAlarm to tell the system to print all stacks on panic. "go test" could pass a higher GOTRACEBACK if GOTRACEBACK isn't set (suggested by @davecheney in #13107 (comment)), but this would affect all test panics (not necessarily a bad thing), and wouldn't help if the test binary was being run directly. Another possibility is that startAlarm could print the stacks itself using runtime.Stack (with "all" set to true) and then simply exit.
The text was updated successfully, but these errors were encountered: