Repository navigation
testing: log the names of running tests when a timeout occurs #39038
Description
Activity
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
Reacted by Bryan C. MillsIndeed. 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. 😅
- changed the title
[-]proposal: testing: log the names of running tests when a timeout occurs[/-][+]testing: log the names of running tests when a timeout occurs[/+]on Nov 1, 2022 - locked and limited conversation to collaborators
on Nov 1, 2023
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
testingpackage produces in case of timeout are not at all helpful.Ideally, the
testingpackage 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.