Skip to content
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

testing: test timeout traceback is not useful #13681

aclements opened this issue Dec 18, 2015 · 2 comments

testing: test timeout traceback is not useful #13681

aclements opened this issue Dec 18, 2015 · 2 comments


Copy link

@aclements aclements commented Dec 18, 2015

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, the runtime test times out with just

panic: test timed out after 5m0s

goroutine 207854 [running]:
    /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.

Copy link

@rsc rsc commented Dec 18, 2015

I have a CL pending for this already.

@rsc rsc closed this in 57337da Dec 18, 2015
@golang golang locked and limited conversation to collaborators Dec 29, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants