JDK-8185706 : [windows] Native callstacks printing terminates prematurely
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2017-08-02
  • Updated: 2019-05-22
  • Resolved: 2017-08-10
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 10
10 b21Fixed
Related Reports
Relates :  
JDK-8185712 - [windows] Improve native symbol decoder
Relates :  
JDK-8022335 - Native stack walk while generating hs_err does not work on Windows x64
Relates :  
JDK-8186349 - [windows] Centralize dbghelp handling code
Description
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 by JDK-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().