Can you reproduce the problem? If so, maybe to find out which thread is
a problem you could check for null, print the thread info, and then fail
the test.
Chris
On 9/4/18 11:14 AM, Gary Adams wrote:
I'm not sure which thread exited causes the NPE.
This patch will let the test continue and at least
let the list of threads be processed.
The test walks up the parents to the initial thread
and then "enumerates()" the set of the threads to check.
There is an inherent race condition in enumerate()
that recognizes it is a snapshot of a moving target.
On 9/4/18, 1:51 PM, Chris Plummer wrote:
Hi Gary,
Why has the thread exited if the debuggee is still running?
Chris
On 9/4/18 5:22 AM, Gary Adams wrote:
Here's a quick fix to avoid the NPE using a getThreadGroup() which
could be null
if the thread has terminated.
Issue: https://bugs.openjdk.java.net/browse/JDK-8210252
diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java
b/test/jdk/com/sun/jdi/DebuggerThreadTest.java
--- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java
+++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java
@@ -77,7 +77,8 @@
int gotThreads = tg.enumerate(list, true);
for (int i = 0; i < Math.min(gotThreads, list.length); i++){
Thread t = list[i];
- String groupName = t.getThreadGroup().getName();
+ ThreadGroup tga = t.getThreadGroup();
+ String groupName = (tga == null ? "<completed>": tga.getName());
System.out.println("Thread [" + i + "] group = '" +
groupName +
