-
Enhancement
-
Resolution: Fixed
-
P4
-
22
-
b07
-
windows
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.
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.
- relates to
-
JDK-8186349 [windows] Centralize dbghelp handling code
- Resolved
-
JDK-8311541 JavaThread::print_jni_stack doesn't support native stacks on all platforms
- Resolved