Saint's Log

Servicability Tests with Bad Core Dumps

I occasionally run into odd test failures in servicability tests like ClhsdbFindPC.java related to core dumps. The test sets a flag to request a crash in order to generate a core dump for inspection. One of the earlier issues was that core dumps were not being created and this was fixed in 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 by swesonga · Pull Request #27074 · openjdk/jdk. A failure I saw recently was:

Aborting due to java.lang.OutOfMemoryError: Metaspace
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (debug.cpp:289), pid=1234, tid=5678
#  fatal error: OutOfMemory encountered: Metaspace
#
# JRE version: OpenJDK Runtime Environment Microsoft-13945457 (25.0.3+9) (build 25.0.3+9-LTS)
# Java VM: OpenJDK 64-Bit Server VM Microsoft-13945457 (25.0.3+9-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-aarch64)
# Core dump will be written. Default location: D:\

The test failure output was:

getCoreFileLocation found stringWithLocation = D:\...\hs_err_pid1234.mdmp
Found core file D:\...\hs_err_pid1234.mdmp, size = 0mb
STDERR:
java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Unexpected core size: expected 0 > 0
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:317)
	at ClhsdbFindPC.main(ClhsdbFindPC.java:339)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.lang.RuntimeException: Unexpected core size: expected 0 > 0
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
	at jdk.test.lib.Asserts.assertGT(Asserts.java:374)
	at jdk.test.lib.util.CoreUtils.getCoreFileLocation(CoreUtils.java:113)
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:113)
	... 5 more

The issue here clearly appears to be that the JVM ran out of memory before it could complete the test. However, I wanted to save the expected output from the test for quick reference in future:

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffaf8cd112c, pid=1234, tid=5678
#
# JRE version: OpenJDK Runtime Environment Microsoft-13945457 (25.0.3+9) (build 25.0.3+9-LTS)
# Java VM: OpenJDK 64-Bit Server VM Microsoft-13945457 (25.0.3+9-LTS, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-aarch64)
# Problematic frame:
# C  [LingeredApp.dll+0x112c]
#
# Core dump will be written. Default location: C:\...

If the test is working correctly, the crash should come from LingeredApp.dll. This binary is in the test image, specifically in hotspot/jtreg/native. LingeredApp.java has a native method called crash(). It’s implementation in libLingeredApp.c dereferences a non-null invalid pointer with set bits in every word. This guarantees that an EXCEPTION_ACCESS_VIOLATION should be seen if the test ran correctly.