commit c7376cabb889eb49cbd2dd9a77d10ee63a53d5b5
author Sebastien Hertz <shertz@google.com> Mon Sep 08 10:15:19 2014 +0200
committer Sebastien Hertz <shertz@google.com> Tue Sep 09 09:48:17 2014 +0200
tree 09fef7a9ceb03b21ffa0bbe59485d6b1c9dfdc4d
parent 38510082135a7fb438afb515fa3174596e644e9b

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

(cherry picked from commit 6d06f1b34322d91226c9dcd61e53c2b6731f8bb6)

Change-Id: I9a18c421297608dc3109624111f9fea021a16d24

runtime/monitor.cc

diff --git a/runtime/monitor.cc b/runtime/monitor.cc
index a87d7c1..6123934 100644
--- a/runtime/monitor.cc
+++ b/runtime/monitor.cc
@@ -965,12 +965,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);