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

proposal: testing: log the names of running tests when a timeout occurs #39038

Open
bcmills opened this issue May 13, 2020 · 2 comments
Open

proposal: testing: log the names of running tests when a timeout occurs #39038

bcmills opened this issue May 13, 2020 · 2 comments
Labels
Milestone

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented May 13, 2020

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.

@gopherbot gopherbot added this to the Proposal milestone May 13, 2020
@gopherbot gopherbot added the Proposal label May 13, 2020
@mvdan
Copy link
Member

@mvdan mvdan commented May 15, 2020

Dup of #23601? :)

@mvdan
Copy link
Member

@mvdan mvdan commented May 15, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.