JDK-8311609 : [windows] Native stack printing lacks source information for dynamically loaded dlls
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2023-07-07
  • Updated: 2023-07-20
  • Resolved: 2023-07-13
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 22
22 b07Fixed
Related Reports
Relates :  
JDK-8186349 - [windows] Centralize dbghelp handling code
Relates :  
JDK-8311541 - JavaThread::print_jni_stack doesn't support native stacks on all platforms
Description
When printing the native stack in a test the following was observed:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xc54091]  os::win32::platform_print_native_stack+0x101  (os_windows_x86.cpp:236)
V  [jvm.dll+0x7e28b4]  JavaThread::print_jni_stack+0xc4  (javaThread.cpp:1714)
V  [jvm.dll+0x8ad770]  check_pending_exception+0xf0  (jniCheck.cpp:193)
V  [jvm.dll+0x8a2381]  checked_jni_CallStaticObjectMethod+0xa1  (jniCheck.cpp:1290)
C  [nativeStack.dll+0x1325]

and we have no source information for nativeStack.dll. Upon investigating it was found that symGetLineFromAddr64 was failing due to "module not found". The fix was to expose the SymRefreshModuleList API and to call it in os::win32::platform_print_native_stack before walking the stack. Now we get:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xc54091]  os::win32::platform_print_native_stack+0x101  (os_windows_x86.cpp:236)
V  [jvm.dll+0x7e28b4]  JavaThread::print_jni_stack+0xc4  (javaThread.cpp:1714)
V  [jvm.dll+0x8ad770]  check_pending_exception+0xf0  (jniCheck.cpp:193)
V  [jvm.dll+0x8a2381]  checked_jni_CallStaticObjectMethod+0xa1  (jniCheck.cpp:1290)
C  [nativeStack.dll+0x1325]  thread_start+0x69  (libnativeStack.c:93)
C  [ucrtbase.dll+0x1fb80]  (no source info available)
C  [KERNEL32.DLL+0x84d4]  (no source info available)
C  [ntdll.dll+0x51791]  (no source info available)

I don't know why the Windows system/runtime dlls now also appear in the stack.
Comments
Changeset: 38f74125 Author: David Holmes <dholmes@openjdk.org> Date: 2023-07-13 01:21:06 +0000 URL: https://git.openjdk.org/jdk/commit/38f74125d143750617252b8cb5411c95e52a2a35
13-07-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14796 Date: 2023-07-07 02:21:21 +0000
07-07-2023
noreg-other Testing is covered by the test in JDK-8311541
07-07-2023