-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: log the names of running tests when a timeout occurs #39038
Comments
Dup of #23601? :) |
I never made mine into a proposal though, and it never really got much traction. If you think your proposal has a better chance at moving things forward, I'm all for closing previous issues and instead linking to "previous reports" here. |
I think https://go-review.googlesource.com/c/go/+/446176 fixed this - cc @bcmills @rsc |
Indeed. In retrospect it didn't really need to be a proposal anyway: it doesn't affect any exported API, and also (by definition!) doesn't affect the behavior of any program that ran correctly before. 😅 |
In the course of diagnosing #38797, I attempted to read the test logs to figure out which test was hanging. I was ultimately unsuccessful.
The test in question (
cmd/go.TestScript
) runs a script engine that loads and interprets 400+ independent, parallel subtests, most of which spend the majority of their time blocked on subprocesses. As a result, the goroutine dumps for each subtest are much like all the others, and the tests generally cannot be distinguished by looking at their stack traces.(For an example, see https://build.golang.org/log/88ebe2c2330de9b4651b75152806f9ff0704f30e.)
For such a test, the goroutine dumps that the
testing
package produces in case of timeout are not at all helpful.Ideally, the
testing
package should follow its goroutine dump with a list of all tests and subtests that are “running”: that is, all of the tests that either have not yet blocked ont.Parallel()
, or did block, were released, and have not yet reached the end of the test or subtest function. That would help to isolate any specific cases that happen to be unusually slow or prone to deadlocks.The text was updated successfully, but these errors were encountered: