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
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.
The text was updated successfully, but these errors were encountered:
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.
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. 😅
bcmills
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
Nov 1, 2022
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: