Bug ID: JDK-8366133 Test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach fails on Linux Alpine after JDK-8363949

JDK-8366133 : Test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach fails on Linux Alpine after JDK-8363949

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 26

Priority: P4
Status: Open
Resolution: Unresolved
OS: linux_alpine
CPU: x86_64

Submitted: 2025-08-26
Updated: 2025-09-08

Versions (Unresolved/Resolved/Fixed)

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-8363949 - Incorrect jtreg header in MonitorWithDeadObjectTest.java

Description

After JDK-8363949 fixed the test header and enabled test execution, the test runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach fails on Linux Alpine  in fastdebug .
Error output is
Error: Calling getThreadMXBean()
result: Failed. Unexpected exit from test [exit code: 255]

After enhancing check_exception, we see this :
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

Comments

The test is expected to work on Linux and macOS. Windows is always an odd-case and IIRC AIX stack guards are also quite different. But again AFAICS we should not be running out of stack so why does Alpine/Muscl-C indicate that we are?
08-09-2025
Hi [~dholmes] , [~stuefe] seems we fail in os::stack_shadow_pages_available as David suggested. We run into an error at the end of the method, where we check return sp > (limit + framesize_in_bytes); Seems sp is too small here in out case on Linux Alpine : sp too small - returning false; sp: 0x7fe482b09020 , limit: 0x7fe482b09000, limit + framesize_in_bytes : 0x7fe482b090d8 That's why the Stackoverflow exception . Can the test even work on ALpine? I find already in the test !windows, !aix . So it is OS specific anyway and does not work 'everywhere' .
05-09-2025
I assume there must be some difference ... maybe related to glibc guard page support. Not sure sorry.
04-09-2025
Hi David, thanks for checking! So do you think we have on Linux Alpine some difference (to other Linux versions) regarding the shadow_zone_safe_limit that is used in the os::stack_shadow_pages_available method ?
04-09-2025
I should have just checked the code. We throw here: address sp = os::current_stack_pointer(); if (!os::stack_shadow_pages_available(THREAD, method, sp)) { // Throw stack overflow exception with preinitialized exception. Exceptions::throw_stack_overflow_exception(THREAD, __FILE__, __LINE__, method); return; } where: bool os::stack_shadow_pages_available(Thread thread, const methodHandle& method, address sp) { if (!thread->is_Java_thread()) return false; // Check if we have StackShadowPages above the guard zone. This parameter // is dependent on the depth of the maximum VM call stack possible from // the handler for stack overflow. 'instanceof' in the stack overflow // handler or a println uses at least 8k stack of VM and native code // respectively. const int framesize_in_bytes = Interpreter::size_top_interpreter_activation(method()) wordSize; address limit = JavaThread::cast(thread)->stack_overflow_state()->shadow_zone_safe_limit(); return sp > (limit + framesize_in_bytes); }
27-08-2025
Hi David, I attached the output with -Xlog:exceptions=debug set.
27-08-2025
Can you test with `-Xlog:exceptions=debug` to try and get the true source of the SOE and the stack trace?
27-08-2025
> The only thing I can think of is that the stackbanging code is not working on Alpine Linux (musl C lib?). Yes it is MUSL c lib. [~stuefe] are you aware of issues with stackbanging code on Alpine ?
27-08-2025
[~mbaesken] thanks. That still shows a small stack IMO. The only thing I can think of is that the stackbanging code is not working on Alpine Linux (musl C lib?).
27-08-2025
Increasing the Xss value (e.g. to 4m, 8m, 32m) for the test has not helped. Seems the StackoverflowError is coming from here thread_dump_with_locked_monitors - function https://github.com/openjdk/jdk/blob/28602f3d3ec15b5241a33a46ce43349e6300395d/test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c#L83 jmethodID getThreadMXBeanMethod = (*env)->GetStaticMethodID(env, ManagementFactoryClass, "getThreadMXBean", "()Ljava/lang/management/ThreadMXBean;");
26-08-2025