JDK-8293010 : JDI ObjectReference/referringObjects/referringObjects001 fails: assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2022-08-28
  • Updated: 2022-12-28
  • Resolved: 2022-09-02
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 17 JDK 20
17.0.6Fixed 20 b14Fixed
Related Reports
Relates :  
JDK-8256811 - Delayed/missed jdwp class unloading events
Relates :  
JDK-8291456 - com/sun/jdi/ClassUnloadEventTest.java failed with: Wrong number of class unload events: expected 10 got 4
Description
The following test failed in my jdk-20+12 stress testing:

vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects001/referringObjects001.java

Here's a snippet from the log file:

debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: deleteInstances:java.lang.String:2
debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: deleteReferrers:java.lang.String:5
debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: createInstances:java.lang.String:4:10:JNI_LOCAL
debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready
debugee.stdout> # To suppress the following error report, specify this argument
debugee.stdout> # after -XX: or in .hotspotrc:  SuppressErrorAt=/jvmtiExport.cpp:1700
debugee.stdout> #
debugee.stdout> # A fatal error has been detected by the Java Runtime Environment:
debugee.stdout> #
debugee.stdout> #  Internal Error (/System/Volumes/Data/work/shared/bug_hunt/thread_SMR_stress/jdk20_exp.git/open/src/hotspot/share/prims/jvmtiExport.cpp:1700), pid=83056, tid=40455
debugee.stdout> #  assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking
debugee.stdout> #
debugee.stdout> # JRE version: Java(TM) SE Runtime Environment (20.0) (slowdebug build 20-internal-2022-08-25-1408339.dcubed...)
debugee.stdout> # Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 20-internal-2022-08-25-1408339.dcubed..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
debugee.stdout> # Core dump will be written. Default location: /cores/core.83056
debugee.stdout> #
debugee.stdout> # An error report file with more information is saved as:
debugee.stdout> # /System/Volumes/Data/work/shared/bug_hunt/thread_SMR_stress/jdk20_exp.git/build/macosx-aarch64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi/scratch/10/hs_err_pid83056.log
debugee.stdout> #
debugee.stdout> # If you would like to submit a bug report, please visit:
debugee.stdout> #   https://bugreport.java.com/bugreport/crash.jsp
debugee.stdout> #
# ERROR: Unexpected exception: com.sun.jdi.VMDisconnectedException
The following stacktrace is for failure analysis.
nsk.share.TestFailure: Unexpected exception: com.sun.jdi.VMDisconnectedException
        at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:432)
        at nsk.share.Log.complain(Log.java:403)
        at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:221)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.run(referringObjects001.java:89)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.main(referringObjects001.java:85)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:1589)
com.sun.jdi.VMDisconnectedException
        at jdk.jdi/com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:304)
        at jdk.jdi/com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1176)
        at jdk.jdi/com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:89)
        at jdk.jdi/com.sun.tools.jdi.JDWP$ReferenceType$Instances.waitForReply(JDWP.java:3006)
        at jdk.jdi/com.sun.tools.jdi.JDWP$ReferenceType$Instances.process(JDWP.java:2982)
        at jdk.jdi/com.sun.tools.jdi.ReferenceTypeImpl.instances(ReferenceTypeImpl.java:955)
        at nsk.share.jdi.HeapwalkingDebugger.getObjectReferences(HeapwalkingDebugger.java:224)
        at nsk.share.jdi.HeapwalkingDebugger.countNewInstances(HeapwalkingDebugger.java:189)
        at nsk.share.jdi.HeapwalkingDebugger.checkDebugeeAnswer_instanceCounts(HeapwalkingDebugger.java:180)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.testReferrerType(referringObjects001.java:160)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.testClass(referringObjects001.java:104)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.doTest(referringObjects001.java:254)
        at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:214)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.run(referringObjects001.java:89)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.main(referringObjects001.java:85)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:1589)
# ERROR: TEST FAILED: debuggee's process finished with status: 134
The following stacktrace is for failure analysis.
nsk.share.TestFailure: TEST FAILED: debuggee's process finished with status: 134
        at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:432)
        at nsk.share.Log.complain(Log.java:403)
        at nsk.share.jdi.TestDebuggerType2.quitDebuggee(TestDebuggerType2.java:202)
        at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:225)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.run(referringObjects001.java:89)
        at nsk.jdi.ObjectReference.referringObjects.referringObjects001.referringObjects001.main(referringObjects001.java:85)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:1589)
TEST FAILED


#>
#>  SUMMARY: Following errors occured
#>      during test execution:
#>
# ERROR: Unexpected exception: com.sun.jdi.VMDisconnectedException
# ERROR: TEST FAILED: debuggee's process finished with status: 134

Here's the crashing thread's stack trace from the hs_err_pid file:

---------------  T H R E A D  ---------------

Current thread (0x0000000158018410):  JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_vm, id=40455, stack(0x0000000171328000,0x000000017152b000)]
        
Stack: [0x0000000171328000,0x000000017152b000],  sp=0x000000017152a2a0,  free space=2056k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x101a624]  VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x868  (jvmtiExport.cpp:1700)
V  [libjvm.dylib+0x101ac54]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x68
V  [libjvm.dylib+0x560528]  report_vm_error(char const*, int, char const*, char const*, ...)+0x88
V  [libjvm.dylib+0xb1ed98]  JvmtiExport::post_object_free(JvmtiEnv*, GrowableArray<long>*)+0xb4
V  [libjvm.dylib+0xb48e5c]  JvmtiTagMap::post_dead_objects(GrowableArray<long>*)+0x80   
V  [libjvm.dylib+0xb4a8f4]  JvmtiTagMap::follow_references(int, Klass*, _jobject*, jvmtiHeapCallbacks const*, void const*)+0x198
V  [libjvm.dylib+0xb01d08]  JvmtiEnv::FollowReferences(int, _jclass*, _jobject*, jvmtiHeapCallbacks const*, void const*)+0x134
V  [libjvm.dylib+0xab38f0]  jvmti_FollowReferences(_jvmtiEnv*, int, _jclass*, _jobject*, jvmtiHeapCallbacks const*, void const*)+0x188
C  [libjdwp.dylib+0x42ce0]  classInstances+0x168
C  [libjdwp.dylib+0x9eb8]  instances+0x9c
C  [libjdwp.dylib+0x1a5a8]  debugLoop_run+0x210
C  [libjdwp.dylib+0x387b8]  connectionInitiated+0xf8
C  [libjdwp.dylib+0x38318]  attachThread+0x7c
V  [libjvm.dylib+0xb2b010]  JvmtiAgentThread::call_start_function()+0x74
V  [libjvm.dylib+0xb2af44]  JvmtiAgentThread::start_function_wrapper(JavaThread*, JavaThread*)+0x60
V  [libjvm.dylib+0x8beb1c]  JavaThread::thread_main_inner()+0x118
V  [libjvm.dylib+0x8be9f8]  JavaThread::run()+0x124
V  [libjvm.dylib+0xf76a64]  Thread::call_run()+0x154
V  [libjvm.dylib+0xd4b524]  thread_native_entry(Thread*)+0x138
C  [libsystem_pthread.dylib+0x7878]  _pthread_start+0x140
Comments
Critical Fix Request [17u] Please see the comment above. I think we should bring this fix to 17.0.6. The fix is simple and addresses an obvious regression in this update, so it should qualify for a push to jdk17u. SAP nightly testing passed.
27-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u/pull/364 Date: 2022-12-24 10:26:26 +0000
24-12-2022
After backporting JDK-8291456 and JDK-8256811 to 17.0.6 we see vmTestbase/nsk/jdi/ReferenceType/instances/instances001/instances001.java throwing this assertion. This happened before in our CI for jdk10 on 29.7.22. It only happens sporadic one one linuxx86_64 machine.
24-12-2022
Changeset: 99c3ab01 Author: Serguei Spitsyn <sspitsyn@openjdk.org> Date: 2022-09-02 01:59:32 +0000 URL: https://git.openjdk.org/jdk/commit/99c3ab01773fcab885aa041345aab1a1ad4d852f
02-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10109 Date: 2022-08-31 21:47:05 +0000
31-08-2022
I've attached the logs from my sighting in my jdk-20+12 macosx-aarch64 stress testing: $ unzip -l jdk-20+12_macosx-aarch64.8293010.zip Archive: jdk-20+12_macosx-aarch64.8293010.zip Length Date Time Name --------- ---------- ----- ---- 41462 08-27-2022 09:32 jdk-20+12_3/failures.macosx-aarch64/referringObjects001.jtr.slowdebug 80423 08-27-2022 09:32 jdk-20+12_3/failures.macosx-aarch64/hs_err_pid83056.log --------- ------- 121885 2 files
28-08-2022
There's another unresolved bug that mentions the same assertion failure: JDK-8291456 com/sun/jdi/ClassUnloadEventTest.java failed with "Wrong number of class unload events: expected 10 got 4" with a different test.
28-08-2022