Fix a thread state misunderstanding.
Note that this means that we now give the right answer for Object.wait(long)
but the wrong answer for Thread.sleep(long). It's not obvious how to easily
fix the latter. It seems like the easiest fix will be to check the class of
the object that's being waited on, and using TS_SLEEPING if it's a ThreadLock;
we already do similar in the stack dumping.
Change-Id: I83c0c54af1061e1678cefe7b07389dd10c2ea3d5
diff --git a/src/debugger.cc b/src/debugger.cc
index 4961edc..5a1b1ad 100644
--- a/src/debugger.cc
+++ b/src/debugger.cc
@@ -1375,10 +1375,12 @@
return false;
}
+ // TODO: if we're in Thread.sleep(long), we should return TS_SLEEPING,
+ // even if it's implemented using Object.wait(long).
switch (thread->GetState()) {
case Thread::kTerminated: *pThreadStatus = JDWP::TS_ZOMBIE; break;
case Thread::kRunnable: *pThreadStatus = JDWP::TS_RUNNING; break;
- case Thread::kTimedWaiting: *pThreadStatus = JDWP::TS_SLEEPING; break;
+ case Thread::kTimedWaiting: *pThreadStatus = JDWP::TS_WAIT; break;
case Thread::kBlocked: *pThreadStatus = JDWP::TS_MONITOR; break;
case Thread::kWaiting: *pThreadStatus = JDWP::TS_WAIT; break;
case Thread::kInitializing: *pThreadStatus = JDWP::TS_ZOMBIE; break;