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-08-26
  • 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 26
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 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
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
[~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