JDK-8347002 : runtime/NMT/CheckForProperDetailStackTrace.java fails to find expected stacktrace
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 24
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux,windows
  • Submitted: 2025-01-04
  • Updated: 2025-04-14
  • Resolved: 2025-04-09
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 25
25Resolved
Related Reports
Duplicate :  
JDK-8350429 - runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM
Description
Test
runtime/NMT/CheckForProperDetailStackTrace.java

fails with 
java.lang.RuntimeException: Expected source information missing from output
	at CheckForProperDetailStackTrace.main(CheckForProperDetailStackTrace.java:144)
	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:1447)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected source information missing from output
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected source information missing from output

See full log in attachment. Test failed on both Linux Ubuntu 24.10 and Windows 2025.
Comments
This bug was fixed by JDK-8350429, closing as duplicate.
09-04-2025
It's not the stack trace that's missing, it's the source information that is missing. This is an optional feature which depends on the source info being present along with the JVM. The source info is assumed to be present on Windows and Linux. This is separate from the TestSymbolsInHsErrFile.java issue, as this looks for function symbols, and not source info. As an example of what it should look like: [0x00007ca821767eff]ResourceHashtableBase<FixedResourceHashtableStorage<109u, SymbolHandleBase<false>, ModuleEntry*>, SymbolHandleBase<false>, ModuleEntry*, (AnyObj::allocation_type)2, (MemTag)20, &SymbolHandleBase<false>::compute_hash, &(bool primitive_equals<SymbolHandleBase<false> >(SymbolHandleBase<false> const&, SymbolHandleBase<false> const&))>::put(SymbolHandleBase<false> const&, ModuleEntry* const&)+0x71 (resourceHash.hpp:177) [0x00007ca82176577a]ModuleEntryTable::locked_create_entry(Handle, bool, Symbol*, Symbol*, Symbol*, ClassLoaderData*)+0x1ea (moduleEntry.cpp:618) [0x00007ca820dd39c2]ClassLoader::create_javabase()+0xb8 (classLoader.cpp:1675) [0x00007ca820dd3668]ClassLoader::classLoader_init2(JavaThread*)+0x26 (classLoader.cpp:1632) ((malloc=56 type=Module #1) (at peak)) Probably, the test is simply too relaxed with what it assumes has source information.
17-03-2025
Failures with similar symptoms were observed on Linux. Log produced on Ubuntu 22.04 x86-64 is attached - see CheckForProperDetailStackTrace_Ubunto2204x64.jtr
11-03-2025
The first failure looks like it may be happening due to the jtharness output overflow. But the previous stack check is passing even though that does not appear in the log file either. ?? The runtime/ErrorHandling/TestSymbolsInHsErrFile.java failure appears to show that the symbols were not in fact present.
06-01-2025
I suspect that runtime/ErrorHandling/TestSymbolsInHsErrFile.java fails because of the same problem. stdout: [# # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd1cac7f2d, pid=10144, tid=5496 # # JRE version: Java(TM) SE Runtime Environment (24.0+27) (fastdebug build 24-ea+27-3551) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-ea+27-3551, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # V [jvm.dll+0x1047f2d] # # CreateCoredumpOnCrash turned off, no core file dumped # # An error report file with more information is saved as: # C:\\VM\\No_27\\results\\JTwork\\runtime\\ErrorHandling\\TestSymbolsInHsErrFile\\hs_err_pid10144.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ]; stderr: [] exitValue = 1 java.lang.RuntimeException: '# V \\[jvm.dll.*\\].*(crash_with_segfault|controlled_crash).*' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372) at TestSymbolsInHsErrFile.main(TestSymbolsInHsErrFile.java:70) 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:1447) JavaTest Message: Test threw exception: java.lang.RuntimeException: '# V \\[jvm.dll.*\\].*(crash_with_segfault|controlled_crash).*' missing from stdout/stderr JavaTest Message: shutting down test
04-01-2025