Move spammy logs to JDWP verbose mode
We are spammed by warning messages when debugging, especially each time we
suspend/resume all threads (to update instrumentation or collect monitor info).
It's common to get into the cases where these warnings are logged so they
shouldn't be warning but debug messages.
This CL moves these LOG(WARNING) to VLOG(jdwp) to not disturb developers when
debugging their app (especially when looking for specific messages in logcat).
We keep them in JDWP verbose mode because they help knowing when we initiate
these sequences of "suspend/resume all threads".
Also adds debug suspend count in the log message for more context.
Bug: 17524544
Bug: 17170697
Change-Id: Ic87985ac6913151d15fd89849e41bde61092c3dd
diff --git a/runtime/jdwp/jdwp_event.cc b/runtime/jdwp/jdwp_event.cc
index fc39cc4..3b1cfd7 100644
--- a/runtime/jdwp/jdwp_event.cc
+++ b/runtime/jdwp/jdwp_event.cc
@@ -295,9 +295,6 @@
/*
* 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;
@@ -317,7 +314,11 @@
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 @@
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);
