commit 6d06f1b34322d91226c9dcd61e53c2b6731f8bb6
author Sebastien Hertz <shertz@google.com> Mon Sep 08 10:15:19 2014 +0200
committer Sebastien Hertz <shertz@google.com> Mon Sep 08 10:18:18 2014 +0200
tree 42e741ac4fe837938a8a20a1bd383aa92b6228b6
parent 20632daac36995947d2d1943f89f07ac277e61f0

Fix monitor visit for class initializer

We do not hold class object's lock when invoking class initializer. Therefore
it is wrong to visit it when looking for monitors owned by a thread.

Bug: 17377924

Change-Id: I7fddcdb9a554301e040c571971eec9be6cba5eda

runtime/monitor.cc

diff --git a/runtime/monitor.cc b/runtime/monitor.cc
index 0b6e3b2..03f8687 100644
--- a/runtime/monitor.cc
+++ b/runtime/monitor.cc
@@ -999,12 +999,6 @@
     return;
   }
 
-  // <clinit> is another special case. The runtime holds the class lock while calling <clinit>.
-  if (m->IsClassInitializer()) {
-    callback(m->GetDeclaringClass(), callback_context);
-    // Fall through because there might be synchronization in the user code too.
-  }
-
   // Is there any reason to believe there's any synchronization in this method?
   const DexFile::CodeItem* code_item = m->GetCodeItem();
   CHECK(code_item != NULL) << PrettyMethod(m);