JDK-7184993 : NPG: assert(Self->_Stalled == 0) failed: invariant
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2012-07-18
  • Updated: 2014-02-12
  • Resolved: 2012-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8-poolResolved
Related Reports
Duplicate :  
JDK-6964458 - Reimplement class meta-data storage to use native memory
Relates :  
JDK-8034785 - Assert when recursively trying to take the monitor from JVMTI MonitorContendedEnter
Description
Assertion failure

#  Internal Error (/tmp/jprt/P1/214551.cphillim/s/src/share/vm/runtime/objectMonitor.cpp:349), pid=17694, tid=44
#  assert(Self->_Stalled == 0) failed: invariant

hs_err log attached.
Comments
EVALUATION This was fixed during development so closed as a duplicate of bug 6964458. This assert should really say something about taking out an object lock on one you already own.
05-09-2012
PUBLIC COMMENTS This looks familiar. The problem is caused by reentrant use of the low-level lock code (which is not reentrant) due to calling out to a JVMTI event hook during lock acquisition: V [libjvm.so+0xa94f7e] void report_vm_error(const char*,int,const char*,const char*)+0x53a;; __1cPreport_vm_error6Fpkci11_v_+0x53a V [libjvm.so+0x170b3b3] void ObjectMonitor::enter(Thread*)+0x833;; __1cNObjectMonitorFenter6MpnGThread__v_+0x833 V [libjvm.so+0x1a42a9b] ObjectLocker::ObjectLocker #Nvariant 1(Handle,Thread*,bool)+0x38f;; __1cMObjectLocker2t6MnGHandle_pnGThread_b_v_+0x38f V [libjvm.so+0x166e42d] _jmethodID*methodOopDesc::make_jmethod_id(ClassLoaderData*,methodOopDesc*)+0x181;; __1cNmethodOopDescPmake_jmethod_id6FpnPClassLoaderData_p0_pnK_jmethodID__+0x181 V [libjvm.so+0xda34ad] _jmethodID*instanceKlass::get_jmethod_id(instanceKlassHandle,methodHandle)+0x289;; __1cNinstanceKlassOget_jmethod_id6FnTinstanceKlassHandle_nMmethodHandle__pnK_jmethodID__+0x289 V [libjvm.so+0x127a7f2] jvmtiError JvmtiEnvBase::get_frame_location(JavaThread*,int,_jmethodID**,long long*)+0x512;; __1cMJvmtiEnvBaseSget_frame_location6MpnKJavaThread_ippnK_jmethodID_px_nKjvmtiError__+0x512 V [libjvm.so+0x1267016] jvmtiError JvmtiEnv::GetFrameLocation(JavaThread*,int,_jmethodID**,long long*)+0x96;; __1cIJvmtiEnvQGetFrameLocation6MpnKJavaThread_ippnK_jmethodID_px_nKjvmtiError__+0x96 V [libjvm.so+0x11a8e2a] jvmti_GetFrameLocation+0x65a;; jvmti_GetFrameLocation+0x65a C [libjdwp.so+0x19225] cbMonitorContendedEnter+0x14d;; cbMonitorContendedEnter+0x14d V [libjvm.so+0x12c89c7] void JvmtiExport::post_monitor_contended_enter(JavaThread*,ObjectMonitor*)+0x11d7;; __1cLJvmtiExportbCpost_monitor_contended_enter6FpnKJavaThread_pnNObjectMonitor__v_+0x11d7 V [libjvm.so+0x170add0] void ObjectMonitor::enter(Thread*)+0x250;; __1cNObjectMonitorFenter6MpnGThread__v_+0x250 The thread is in enter and has executed: // We've encountered genuine contention. assert (Self->_Stalled == 0, "invariant") ; Self->_Stalled = intptr_t(this) ; and then: { // Change java thread status to indicate blocked on monitor enter. JavaThreadBlockedOnMonitorEnterState jtbmes(jt, this); DTRACE_MONITOR_PROBE(contended__enter, this, object(), jt); if (JvmtiExport::should_post_monitor_contended_enter()) { JvmtiExport::post_monitor_contended_enter(jt, this); } JVMTI then causes a nested lock attempt, we comes back into enter and hit the assert (Self->_Stalled == 0, "invariant") ;
19-07-2012