Add ability for timeout to print full thread stack dump #463
Comments
|
It would be quite easy to write a custom Rule to do this; I wonder if we should change |
|
I am a bit of a noob when it comes to advanced JUnit. Is there a way to apply a Rule to all tests in a large maven project, without manually annotating every last test with @rule? Seems a bit repetitive to add to all ~4000 test cases, and hard to remind people to add it to new cases as they add them. |
|
I assume you want every test method in your project to have a specified timeout. If so, I don't know of a way to add a timeout to all the test methods in your project. You could have the test classes that need a timeout inherit from a base class that has the rule declared. I believe you could also specify a timeout for an entire suite by adding a You could, of course, write a custom runner that applied a timeout to all of the tests that used the runner, but you would have to update all your test classes to use the custom runner, which would be just as much work as adding a Rule but would be less flexible. |
|
@toddlipcon, how is your timeout being set currently? Are you running through ant or maven, which supply their own timeouts? |
|
We're setting timeout on each test with a @timeout annotation. But, this is a nuisance too -- people often forget to add timeouts, and it's much harder to diagnose those failures. So a global rule (and timeout) setting would be helpful. To answer the other question, we currently run the tests through maven using surefire (the project in question is Apache Hadoop). |
|
Let's split the bugs: one is printing out more than one thread stacktrace when a test times out (ideally, I take it, triggered by the @timeout annotation). Two is a global setting that affects all methods by adding a timeout. Both are interesting. Which should we track in this feature request, and which should we move to a new request? Thanks. |
|
Let's keep this one about the multi-thread stack dump, and separately talk about the global rule application. Sound good? |
|
Works for me. One concern I have about the multi-thread dump is that there may be many threads in flight, only some of which are interesting to the test. Would it make sense to ask users to somehow tag or register the threads they would eventually need stacktraces for? |
|
I'd rather err on the side of giving all the threads in the dump (same as a SIGQUIT). Perhaps have some way to allow users to tag threads as un-interesting, but seems like when you're debugging a failure, it's not too bad to manually ignore the threads you don't care about. Whereas by default you'd like to see all the threads you spawned. |
|
What about introducing three types of runners dumping Registering threads in a global instance may introduce memory leaks and/or app hangs. |
|
Ah, the hamcrest matcher is quite a clever idea. I would have the matcher actually take the thread itself, instead of just the thread's name (eg a user might already have convenient marker interfaces attached to their threads) |
|
it seems the solution already exists |
|
Yep, that's basically what I'm looking for without having the extra complexity of getting a different version of junit on the maven classpath to build, etc. I think these should be common enough use cases that it belongs in "stock" junit without every project having to customize it. Maybe that's against the JUnit philosophy though. |
|
never mind, but look at the code. |
|
If it would solve your problem and @dsaff accepts a new feature in pull request, then you may have it in some of the next junit release. I underastand selecting threads just as another feature for you, or did i miss something? |
|
I think the basic idea makes sense. Someone should try a first-cut implementation, and see whether there's a way to make the information available without also cluttering the main output. |
|
#742 is a clear first step in this direction. |
junit-team#463: Add ability for timeout to print full thread stack dump - Naive attempt that (a) optionally adds information from ThreadMXBean#findMonitorDeadlockedThreads and (b) always adds full thread dump to exception message
junit-team#463 Add ability for timeout to print full thread stack dump - Another attempt that allows to "install" an additional custom timeout handler that can optionally also add a further exception to the test timeout exception
junit-team#463 Add ability for timeout to print full thread stack dump - Another attempt that allows to "install" an additional custom timeout handler that can optionally also add a further exception to the test timeout exception - Fix: remove outdated TODO comment
junit-team#463 Add ability for timeout to print full thread stack dump - Extend the attempt that allows to "install" an additional custom timeout handler (that can optionally also add a further exception to the test timeout exception) by a globally set custom timeout handler based on a system property: note this fails in Ant context; and deadlocked threads of self tests are surviving; so this is by no means finished
junit-team#463 Add ability for timeout to print full thread stack dump - Ref tests and where the test thread is interrupted to prevent surviving threads (as it is the case for other older tests!), reduce duplication in test code
Motivation: See netty#3172 Modifications: Copy TimedOutTestsListener from Apache Hadoop(https://github.com/apache/hadoop/blob/d1c6accb6f87b08975175580e15f1ff1fe29ab04/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/test/TimedOutTestsListener.java) into the "common" project and add `output.flush()`. If not calling `flush`, the output may be printed to the console. In addition, also update the `pom.xml`s to set up the timeout listener. This is a workaround before junit adds such listener (junit-team/junit4#463). Result: If a test is set the timeout paramter using junit's `@Test(timeout = ...)` and the timeout is triggered, a full stack trace dump will be outputted and also output the deadlocks if any.
When using JUnit to run integration-style tests which involve several threads, or to test multi-threaded components, a deadlock or livelock bug can often result in a test timeout. The current behavior only provides the stack trace of the main test thread, which is not always sufficient to understand the true cause of the deadlock (the main thread may just be blocked on another worker thread).
I'd like to add the ability to dump all of the thread stacks to stderr when a timeout is triggered. Does this seem like a reasonable default behavior, or something best enabled via some kind of property/configuration?
The text was updated successfully, but these errors were encountered: