JDK-8024363 : Native stack printing on Win/x64 cannot print the Java frames
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows
  • CPU: x86
  • Submitted: 2013-09-05
  • Updated: 2015-03-09
  • Resolved: 2015-03-09
Related Reports
Relates :  
JDK-8022335 - Native stack walk while generating hs_err does not work on Windows x64
Relates :  
JDK-8024364 - Win/x64: os::current_frame() and os::fetch_frame_from_context() returns wrong frame pointer.
Description
This bug is filed to cover an issue missed by the JDK-8022335 fix.

The JDK-8022335 fix is based on StackWalk64, which knows nothing about the Java frames. So hs_err will display only the native frames, and stop as soon as the first Java frame is reached. It will also NOT display any native frames below Java frames.

Ideally, we want to be able to print the entire call stack

    [native frames #1]
    [java frames #1]
    [native frames #2]
    [java frames #2]
    ...
    [native frames #N]
    [java frames #N]

Printing the Java frames immediately below the first set of native frames (i.e., [java frames #1]) should be doable. As StackWalk64() walks to the caller at the bottom-most frame of [native frames #1], the RIP, RBP and RFP (stored inside the CONTEXT structure) should be the proper values for the top-most frame of [java frames #1].

However, the transition from [java frames #1] -> [native frames #2] may not work, if any of the frames in [native frames #2] use a frame pointer register, which on WinX64 may not be RBP. See http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-August/009098.html for more info.
Comments
We print the first native frames and the next section will contain the java frames. This provides the information necessary. For a complete stacktrace with multiple layers of java/native frames you can always look in the mdmp file. Closing as WNF.
09-03-2015