Description
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 on t.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.