From: Sebastien Hertz <shertz@google.com>
Date: Mon, 8 Sep 2014 08:15:19 +0000 (+0200)
Subject: Fix monitor visit for class initializer
X-Git-Tag: android-x86-6.0-r1~145^2~2^2~219^2
X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=6d06f1b34322d91226c9dcd61e53c2b6731f8bb6;p=android-x86%2Fart.git

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
---

diff --git a/runtime/monitor.cc b/runtime/monitor.cc
index 0b6e3b25f..03f86874b 100644
--- a/runtime/monitor.cc
+++ b/runtime/monitor.cc
@@ -999,12 +999,6 @@ void Monitor::VisitLocks(StackVisitor* stack_visitor, void (*callback)(mirror::O
     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);