Timeout exceptions should have stack trace from stuck thread #727
Comments
|
This is a good idea. |
|
Hello, I'm pretty new to open source projects, so I apologize if I don't get all the mechanics of pushing and pulling and branching correct. Anyway, I have a fix for this issue and I'll make a pull request soon unless somebody thinks I fixed it wrong and wants me to change something. Anyway, my thinking is that we wouldn't want to add the stack of the executing thread instead of the stack it's currently displaying, because that would lose information that could be valuable. The fixes I added will cause both stacks to be displayed, if it's determined that some thread (other than the "main" thread used to start the test) was causing a problem. A technical detail: I looked into it but I don't think it's possible for the JRE to tell the program which thread it happened to be executing at the point where the timeout occurs. What I did was to set up a ThreadGroup to hold the thread that runs the test; then any threads created by the test will normally be part of that ThreadGroup or a subgroup. Then it's possible to look for all threads in the group (and subgroups) and see if exactly one is RUNNABLE; if so, it assumes that's the one that's stuck. If there are more than one, it tries to determine which one has used the most CPU time. I think this would provide the kind of information that the requester or another user would find useful. |
#727 Fail on timeout displays stack of stuck thread
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
|
Fixed by #742. |
It would be very helpful if tests with timeouts (I tend to use
@Test(timeout = ...)) failed with exceptions that had a stack trace from the thread that was stuck or slow.If a reference to the executing thread is saved (storing this information somewhere could be the first thing it does), then
Thread.getStackTrace()will be available for inspection. The exception itself, however, would need to be special, because exceptions don't normally work with a saved array of stack frames, but instead appears to call into native code to generate the stack frame array every time it is needed.The text was updated successfully, but these errors were encountered: