Fix a couple of JDWP bugs.
A couple of JDWP tests started failing when we made "thread suspend
count is already zero" into a fatal error. This patch makes the debugger
a bit more careful about doing silly things (the JDWP protocol defines
these silly things as no-ops, and it's surprisingly easy for an end
user to get us into this state; just sit typing "resume" at the jdb(1)
prompt, for example).
I've also tidied up GetObjectTag to return an error on failure, but
that isn't the fix to any bug the tests find. (The only remaining JDWP
bugs are all caused by an inability to cope with register promotion,
and we're already working on the proper fix for that.)
Change-Id: I671f62234b5cb41aa9d86c6b947c518d7c068800
diff --git a/src/debugger.cc b/src/debugger.cc
index eb5efa2..29cb965 100644
--- a/src/debugger.cc
+++ b/src/debugger.cc
@@ -732,9 +732,13 @@
return JDWP::ERR_NONE;
}
-uint8_t Dbg::GetObjectTag(JDWP::ObjectId objectId) {
+JDWP::JdwpError Dbg::GetObjectTag(JDWP::ObjectId objectId, uint8_t& tag) {
Object* o = gRegistry->Get<Object*>(objectId);
- return TagFromObject(o);
+ if (o == kInvalidObject) {
+ return JDWP::ERR_INVALID_OBJECT;
+ }
+ tag = TagFromObject(o);
+ return JDWP::ERR_NONE;
}
size_t Dbg::GetTagWidth(JDWP::JdwpTag tag) {
@@ -1543,7 +1547,9 @@
LOG(WARNING) << "No such thread for resume: " << peer;
return;
}
- Runtime::Current()->GetThreadList()->Resume(thread, true);
+ if (thread->GetSuspendCount() > 0) {
+ Runtime::Current()->GetThreadList()->Resume(thread, true);
+ }
}
void Dbg::SuspendSelf() {