JDK-8363949 : Incorrect jtreg header in MonitorWithDeadObjectTest.java
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-07-23
  • Updated: 2025-11-30
  • Resolved: 2025-07-31
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 21 JDK 25 JDK 26
21.0.11-oracleFixed 25.0.3-oracleFixed 26 b10Fixed
Related Reports
Causes :  
JDK-8320515 - assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object
Relates :  
JDK-8366133 - Test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach fails on Linux Alpine fastdebug after JDK-8363949
Description
Running test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java fails with

Error: Not a test or directory containing tests: runtime/Monitor/MonitorWithDeadObjectTest.java

Because the jtreg header lists the @bug before the @test.

UPD: It is the @requires tag which causes the problem, not the @bug. It is sufficient to place @requires right after @test, which should be the 1st tag for every test.
Comments
Fix request [25u,21u] I backport this for parity with 25.0.3-oracle,21.0.11-oracle. No risk, only a test change. Clean backport. Test passes. SAP nighlyt shows failures on alpine. Thus defer-next or until JDK-8366133 is fixed.
30-11-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/2495 Date: 2025-11-28 15:56:47 +0000
28-11-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk25u-dev/pull/35 Date: 2025-11-28 15:56:37 +0000
28-11-2025
Hi [~dholmes] I created JDK-8366133 ; probably we should add the enhancement to check_exception too, to get in other cases also a bit more meaningful output.
26-08-2025
> Wondering why it only occurs on Linux Alpine? Btw it shows on Linux Alpine fastdebug ; product worked, the error is not observed there - maybe some 'bad' debug only coding? Or even a compiler issue ? >Maybe a high -Xss setting for this test would help here Unfortunately setting Xss in the test did not help, test still fails. Btw. when uncommenting all the check(..) calls from function static void thread_dump_with_locked_monitors(JNIEnv* env) {...} and this way ignoring the mentioned StackoverflowError, the test passes. Not sure if this is okay to ignore those exceptions, probably not?
26-08-2025
[~mbaesken] please file a new issue. I have no idea how/why we would encounter a StackOverflowError here. Unfortunately I also don't have the environment to investigate it.
25-08-2025
Hi [~dholmes] should I open a separate JBS issue? Could we get more details about the StackOverflowError ? Wondering why it only occurs on Linux Alpine? Maybe a high -Xss setting for this test would help here , or do you think we run into a bad recursion so that it would not make a difference ?
25-08-2025
That is very strange. Interesting but strange. The stack doesn't look large enough to have been exhausted.
22-08-2025
> Let's see what ExceptionDescribe tells us. we get now this output : Exception in thread "Thread-1" java.util.ServiceConfigurationError: sun.management.spi.PlatformMBeanProvider: Provider com.sun.management.internal.PlatformMBeanProviderImpl could not be instantiated at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:552) at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:712) at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:672) at java.base/java.util.ServiceLoader$2.next(ServiceLoader.java:1256) at java.management/java.lang.management.ManagementFactory$PlatformMBeanFinder.<clinit>(ManagementFactory.java:901) at java.management/java.lang.management.ManagementFactory.getPlatformMXBean(ManagementFactory.java:668) at java.management/java.lang.management.ManagementFactory.getThreadMXBean(ManagementFactory.java:349) Caused by: java.lang.StackOverflowError at java.base/java.lang.Class.getConstantPool(Native Method) at java.base/java.lang.System$1.getConstantPool(System.java:2005) at java.base/java.lang.reflect.Executable.declaredAnnotations(Executable.java:671) at java.base/java.lang.reflect.Executable.declaredAnnotations(Executable.java:666) at java.base/java.lang.reflect.Executable.getAnnotation(Executable.java:634) at java.base/java.lang.reflect.Method.getAnnotation(Method.java:778) at java.base/java.lang.reflect.AnnotatedElement.isAnnotationPresent(AnnotatedElement.java:291) at java.base/java.lang.reflect.AccessibleObject.isAnnotationPresent(AccessibleObject.java:515) at java.base/jdk.internal.reflect.Reflection.isCallerSensitive(Reflection.java:354) at java.base/java.lang.reflect.Method.isCallerSensitive(Method.java:603) at java.base/java.lang.reflect.Method.invoke(Method.java:546) at java.base/java.lang.Class.getEnumConstantsShared(Class.java:3445) at java.base/java.lang.System$1.getEnumConstantsShared(System.java:2030) at java.base/java.util.EnumMap.getKeyUniverse(EnumMap.java:751) at java.base/java.util.EnumMap.<init>(EnumMap.java:138) at java.base/java.util.stream.StreamOpFlag.set(StreamOpFlag.java:396) at java.base/java.util.stream.StreamOpFlag.<clinit>(StreamOpFlag.java:248) at java.base/java.util.stream.StreamSupport.stream(StreamSupport.java:70) at java.base/java.util.Arrays.stream(Arrays.java:5483) at java.base/java.util.Arrays.stream(Arrays.java:5464) at java.base/java.util.stream.Stream.of(Stream.java:1477) at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl$1.<init>(PlatformMBeanProviderImpl.java:76) at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl.init(PlatformMBeanProviderImpl.java:73) at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl.<init>(PlatformMBeanProviderImpl.java:60) at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483) at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:707) ... 5 more Error: Calling getThreadMXBean()
19-08-2025
Hi David, thanks for the suggestion. Let's see what ExceptionDescribe tells us.
18-08-2025
[~mbaesken] First, yes this change "enabled" the test and it was not running before (more accurately the file was not recognised as containing a test and so was just ignored) Second, I have no idea why this would fail on Alpine Linux. I don't see any of the ThreadMXBean-using tests excluded from running on Linux+musl. I suggest changing the test code as follows: static void check_exception(JNIEnv* env, const char* msg) { if ((*env)->ExceptionCheck(env)) { (*env)->ExceptionDescribe(env); fprintf(stderr, "Error: %s", msg); exit(-1); } } to see what exception is actually being thrown.
18-08-2025
Seems the "Error: Calling getThreadMXBean()" message is coming from this exception check : https://github.com/openjdk/jdk/blob/e320162815d529bc65cd058b34ec39d60d032ce7/test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c#L87 jobject threadBean = (*env)->CallStaticObjectMethod(env, ManagementFactoryClass, getThreadMXBeanMethod); check(env, threadBean, "Calling getThreadMXBean()"); [~dholmes] any idea why this might fail on Linux Alpine?
14-08-2025
Since 1st August 2025, the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach fails with Error: Calling getThreadMXBean() result: Failed. Unexpected exit from test [exit code: 255] on Linux Alpine. Did this change enable the test, and it was not running before ?
13-08-2025
Changeset: c4fbfa21 Branch: master Author: Anton Artemov <anton.artemov@oracle.com> Committer: Albert Mingkun Yang <ayang@openjdk.org> Date: 2025-07-31 15:39:38 +0000 URL: https://git.openjdk.org/jdk/commit/c4fbfa21030c9a0e8a3e0eed1b0a0988eba08ddb
31-07-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26527 Date: 2025-07-29 09:18:40 +0000
29-07-2025
Ah, right. I didn't check in detail, just noticed that the test is not run.
29-07-2025
[~thartmann] I think one can have @bug before @test, as in the common header, but to make it pass standalone it is enough to swap @test and @requires in each test.
29-07-2025
You need to run the test standalone to catch this. Not sure how [~enikitin] found the original issue but I then just wrote a quick script to scan all tests for this.
29-07-2025
[~thartmann] Do you know why this wasn't found in the CI? Do you need to run the test by itself to reproduce this, or is this a new jtreg feature?
28-07-2025