JDK-8290908 : misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows
  • CPU: x86_64,aarch64
  • Submitted: 2022-07-23
  • Updated: 2022-10-28
  • Resolved: 2022-08-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 b09Fixed
Related Reports
Relates :  
JDK-8256811 - Delayed/missed jdwp class unloading events
Description
The following test failed in the JDK20 CI:

vm/jvmti/ObjectFree/ofre001/ofre00101/ofre00101.html

Here's a snippet from the log file:

#section:testExecute
----------messages:(1/1037)----------
command: com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/opt/mach5/mesos/work_dir/jib-master/install/jck/19/b18/extra/bundles/JCK-extra-19.zip/JCK-extra-19/binaries/linux-aarch64/lib /opt/mach5/mesos/work_dir/jib-master/install/jdk-20+8-406/linux-aarch64-debug.jdk/jdk-20/fastdebug/bin/java --enable-preview -Djava.awt.headless=true -XX:+CreateCoredumpOnCrash -XX:+UseSerialGC -XX:MaxRAMPercentage=6.25 --show-version -Xms32m -Xmx1024m -Djdk.attach.allowAttachSelf=true -Djava.security.properties=/opt/mach5/mesos/work_dir/jib-master/install/jck/19/b18/extra/bundles/JCK-extra-19.zip/JCK-extra-19/extra.security.properties -agentlib:jckjvmti=ofre00101 -classpath :/opt/mach5/mesos/work_dir/jib-master/install/jck/19/b18/bundles/JCK-runtime-19.jar/JCK-runtime-19/classes: -Djava.security.policy=/opt/mach5/mesos/work_dir/jib-master/install/jck/19/b18/bundles/JCK-runtime-19.jar/JCK-runtime-19/lib/jck.policy javasoft.sqe.tests.vm.jvmti.ofre001.ofre00101.ofre00101 -platform.jvmtiSupported true -platform.nativeLibsLinkage dynamic
----------out1:(0/0)----------
----------out2:(24/2040)----------
java 20-ea 2023-03-21
Java(TM) SE Runtime Environment (fastdebug build 20-ea+8-406)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 20-ea+8-406, mixed mode, sharing)
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/interfaceSupport.inline.hpp:182
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S10191/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/e31097f9-3ce4-4ac2-99e7-51c0b1efd6b2/runs/05232410-acaf-412b-9e40-7b683475a67e/workspace/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:182), pid=1290327, tid=1290331
#  assert(!thread->owns_locks()) failed: must release all locks when leaving VM
#
# JRE version: Java(TM) SE Runtime Environment (20.0+8) (fastdebug build 20-ea+8-406)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+8-406, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x12c60a8]  JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x148
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S10129/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/95922504-7250-440e-bdd3-057f810cf226/runs/b1e3cd30-b0a4-4610-816e-8cffc4b2885c/testoutput/test-support/jck_runtime_vm_jvmti/core.1290327)
#
# An error report file with more information is saved as:
# /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S10129/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/95922504-7250-440e-bdd3-057f810cf226/runs/b1e3cd30-b0a4-4610-816e-8cffc4b2885c/testoutput/test-support/jck_runtime_vm_jvmti/hs_err_pid1290327.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
result: Failed. unexpected exit code: exit code 134


Unfortunately, the failures artifact link does not show an hs_err_pid file.
Comments
Fix request [17u] on behalf of Andrew Dinn Required follow up of JDK-8256811.
28-10-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/637 Date: 2022-08-18 10:18:57 +0000
18-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/636 Date: 2022-08-17 15:54:39 +0000
17-08-2022
The fix for this bug is integrated in jdk-20+9-493.
03-08-2022
> bash jib.sh mach5 -- --build-id jdk-20+8-406 -b linux-aarch64-debug --test jck:vm/jvmti -a "-XX:+CreateCoredumpOnCrash -XX:+UseSerialGC" I ran the same based on my local repo (unfixed) for 3 debug platforms but it did not fail. My guess is that this issue is intermittent.
02-08-2022
Changeset: 0ae83410 Author: Serguei Spitsyn <sspitsyn@openjdk.org> Date: 2022-08-02 22:41:17 +0000 URL: https://git.openjdk.org/jdk/commit/0ae834105740f7cf73fe96be22e0f564ad29b18d
02-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/9699 Date: 2022-08-01 07:41:50 +0000
01-08-2022
[~cjplummer] I've already tried it but no luck. The JCK tests are passed on all platforms with and w/o the VM options listed in description.
01-08-2022
In fact, I don't know how to reproduce the problem. My local test runs of this tests with the listed VM options are always passed.
29-07-2022
[~zgu] Okay, no problem. I will try to prepare a fix today. In fact, I agree with your suggestion.
29-07-2022
[~sspitsyn] I would like to, but timing is bad. Today is my last day at Red Hat, not sure when I will be able to contribute again ...
29-07-2022
[~zgu] Zhengyu, do you want to fix it yourself? Are you able to tun this test? We did not run the JCK tests. It is why we did not catch this. Please, note, the failure is noisy, so it is better to fix is sooner.
29-07-2022
It is caused by JDK-8256811, as JvmtiExport::post_object_free() call does not expect under any lock. I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. if (event_type == JVMTI_EVENT_OBJECT_FREE) { flush_object_free_events(env); } It is odd that this failure did not show up in JDK-8256811 tests.
26-07-2022
This ap01t001 test was failing during an earlier version of https://github.com/openjdk/jdk/pull/9168. See my comment (and the comments that follow) https://github.com/openjdk/jdk/pull/9168#issuecomment-1181272100. The issue was fixed, but seems this test is sensitive the ObjectFree changes made by this PR.
26-07-2022
I was sure I saw a similar failure report somewhere very recently but cannot find an associated JBS issue - [~sspitsyn] does this ring a bell?
24-07-2022
hs_err file was higher up in the directory under test-support: --------------- T H R E A D --------------- Current thread (0x0000fffea002a3d0): JavaThread "main" [_thread_in_vm, id=1290331, stack(0x0000fffea49a0000,0x0000fffea4ba0000)] Stack: [0x0000fffea49a0000,0x0000fffea4ba0000], sp=0x0000fffea4b9dca0, free space=2039k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x12c60a8] JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x148 V [libjvm.so+0x12bb9e4] JvmtiExport::post_object_free(JvmtiEnv*, GrowableArray<long>*)+0x124 V [libjvm.so+0x12f0bc8] JvmtiTagMap::post_dead_objects(GrowableArray<long>*)+0xa8 V [libjvm.so+0x12f1318] JvmtiTagMap::remove_and_post_dead_objects()+0x154 V [libjvm.so+0x12f1aa4] JvmtiTagMap::flush_object_free_events()+0x1d4 V [libjvm.so+0x12b1518] JvmtiEventControllerPrivate::set_user_enabled(JvmtiEnvBase*, JavaThread*, Handle, jvmtiEvent, bool)+0x144 V [libjvm.so+0x12b21a0] JvmtiEventController::set_user_enabled(JvmtiEnvBase*, JavaThread*, oop, jvmtiEvent, bool)+0x14c V [libjvm.so+0x1284afc] JvmtiEnv::SetEventNotificationMode(jvmtiEventMode, jvmtiEvent, _jobject*, ...)+0x18c V [libjvm.so+0x123e238] jvmti_SetEventNotificationMode+0x114 C [libjckjvmti.so+0x8d438] Java_javasoft_sqe_tests_vm_jvmti_ofre001_ofre00101_ofre00101_notification+0x5c j javasoft.sqe.tests.vm.jvmti.ofre001.ofre00101.ofre00101.notification(Z)V+0 j javasoft.sqe.tests.vm.jvmti.ofre001.ofre00101.ofre00101.run([Ljava/lang/String;Ljava/io/PrintStream;)I+80 j javasoft.sqe.tests.vm.jvmti.ofre001.ofre00101.ofre00101.main([Ljava/lang/String;)V+8 v ~StubRoutines::call_stub 0x0000fffe8fc101bc V [libjvm.so+0xfa22dc] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x5ac V [libjvm.so+0x10e1d80] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) [clone .constprop.1]+0x1bc V [libjvm.so+0x10e5100] jni_CallStaticVoidMethod+0x180 C [libjli.so+0x4828] JavaMain+0xc54
24-07-2022