diff options
| -rw-r--r-- | runtime/jdwp/jdwp_event.cc | 9 | ||||
| -rw-r--r-- | runtime/thread_list.cc | 9 |
2 files changed, 11 insertions, 7 deletions
diff --git a/runtime/jdwp/jdwp_event.cc b/runtime/jdwp/jdwp_event.cc index 46db63c..d61660b 100644 --- a/runtime/jdwp/jdwp_event.cc +++ b/runtime/jdwp/jdwp_event.cc @@ -297,9 +297,6 @@ void JdwpState::UnregisterEvent(JdwpEvent* pEvent) { /* * Remove the event with the given ID from the list. * - * Failure to find the event isn't really an error, but it is a little - * weird. (It looks like Eclipse will try to be extra careful and will - * explicitly remove one-off single-step events.) */ void JdwpState::UnregisterEventById(uint32_t requestId) { bool found = false; @@ -319,7 +316,11 @@ void JdwpState::UnregisterEventById(uint32_t requestId) { if (found) { Dbg::ManageDeoptimization(); } else { - LOG(WARNING) << StringPrintf("Odd: no match when removing event reqId=0x%04x", requestId); + // Failure to find the event isn't really an error. For instance, it looks like Eclipse will + // try to be extra careful and will explicitly remove one-off single-step events (using a + // 'count' event modifier of 1). So the event may have already been removed as part of the + // event notification (see JdwpState::CleanupMatchList). + VLOG(jdwp) << StringPrintf("No match when removing event reqId=0x%04x", requestId); } } diff --git a/runtime/thread_list.cc b/runtime/thread_list.cc index 08e66ea..ec5b775 100644 --- a/runtime/thread_list.cc +++ b/runtime/thread_list.cc @@ -728,11 +728,14 @@ void ThreadList::SuspendSelfForDebugger() { Thread::resume_cond_->Wait(self); if (self->GetSuspendCount() != 0) { // The condition was signaled but we're still suspended. This - // can happen if the debugger lets go while a SIGQUIT thread + // can happen when we suspend then resume all threads to + // update instrumentation or compute monitor info. This can + // also happen if the debugger lets go while a SIGQUIT thread // dump event is pending (assuming SignalCatcher was resumed for // just long enough to try to grab the thread-suspend lock). - LOG(WARNING) << *self << " still suspended after undo " - << "(suspend count=" << self->GetSuspendCount() << ")"; + VLOG(jdwp) << *self << " still suspended after undo " + << "(suspend count=" << self->GetSuspendCount() << ", " + << "debug suspend count=" << self->GetDebugSuspendCount() << ")"; } } CHECK_EQ(self->GetSuspendCount(), 0); |