JDK-8320720 : JNI Locked Monitors can be associated with a dead (null) object
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 22
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-11-26
  • Updated: 2024-04-08
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8320515 - assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object
Description
If JNI is used to lock an object and then all references to the object are dropped without the thread unlocking the object, then we have an in-use inflated ObjectMonitor whose associated object can be null due to it being GC'd.

Prior to  the fix for JDK-8320515, if we run the test for that fix we get:

#  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/services/management.cpp:1274), pid=1546709, tid=1546754
#  assert(object != nullptr) failed: must be a Java object
...
V  [libjvm.so+0x1330ce8]  jmm_DumpThreads+0x1a48  (management.cpp:1274)
j  sun.management.ThreadImpl.dumpThreads0([JZZI)[Ljava/lang/management/ThreadInfo;+0 java.management@22-internal
j  sun.management.ThreadImpl.dumpAllThreads(ZZI)[Ljava/lang/management/ThreadInfo;+28 java.management@22-internal
j  sun.management.ThreadImpl.dumpAllThreads(ZZ)[Ljava/lang/management/ThreadInfo;+5 java.management@22-internal
j  IterateMonitorWithDeadObjectTest.dumpThreadsWithLockedMonitors()V+7
j  IterateMonitorWithDeadObjectTest.main([Ljava/lang/String;)V+11

If we remove that assert we hit an NPE in the Java layer:

java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "lock" is null
	at java.management/java.lang.management.ThreadInfo.<init>(ThreadInfo.java:172)
	at java.management/sun.management.ThreadImpl.dumpThreads0(Native Method)
	at java.management/sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:518)
	at java.management/sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:506)
	at IterateMonitorWithDeadObjectTest.dumpThreadsWithLockedMonitors(IterateMonitorWithDeadObjectTest.java:44)
	at IterateMonitorWithDeadObjectTest.main(IterateMonitorWithDeadObjectTest.java:66)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1570)

After the fix for JDK-8320515 such ObjectMonitors are elided from the set of monitors gathered by ObjectMonitorsDump::do_monitors

We need to decide whether such ObjectMonitors should be included in the results of  jmm_DumpThreads and if so re-enable them and fix the code accordingly to tolerate the possibility of a null object.