On Windows x64, we often do not get native call stacks in the hs-err file. For example, try (in a debug build):
java.exe -XX:ErrorHandlerTest=12
Callstack in the generated hs-err file will be empty.
This was all quite well analyzed byJDK-8022335. However, the actual fix for JDK-8022335, inside the windows version of os::platform_print_native_stack(), still queries the value of the frame pointer before printing it. And then, if the frame pointer is NULL, it just stops printing and returns.
I found that the cases where call stack dumping on Windows x64 works it does so out of accident: the frame pointer was still set from some frame above the crashing frame. In these cases, the frame pointer is not really needed neither for printing nor by StackWalk64(), because stacks print correctly despite the fact that the frame pointer is incorrect.
The proposed solution is to not test the frame pointer value in Windows' os::platform_print_native_stack().
java.exe -XX:ErrorHandlerTest=12
Callstack in the generated hs-err file will be empty.
This was all quite well analyzed by
I found that the cases where call stack dumping on Windows x64 works it does so out of accident: the frame pointer was still set from some frame above the crashing frame. In these cases, the frame pointer is not really needed neither for printing nor by StackWalk64(), because stacks print correctly despite the fact that the frame pointer is incorrect.
The proposed solution is to not test the frame pointer value in Windows' os::platform_print_native_stack().
- relates to
-
JDK-8185712 [windows] Improve native symbol decoder
-
- Resolved
-
-
JDK-8186349 [windows] Centralize dbghelp handling code
-
- Resolved
-
-
JDK-8022335 Native stack walk while generating hs_err does not work on Windows x64
-
- Closed
-