RFR (S) 8022335 - Native stack walk while generating hs_err does not work on Windows x64

[Vladimir Kozlov]

For your information I am pushing next related changes:

http://cr.openjdk.java.net/~kvn/8021898/webrev/src/share/vm/utilities/vmError.cpp.cdiff.html

Vladimir

On 8/14/13 3:11 PM, Ioi Lam wrote:
> |Please review this fix:||
> ||
> ||http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_001/||
> ||
> ||Bug: Native stack walk while generating hs_err does not work on
> Windows x64||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022335||
> ||https://jbs.oracle.com/bugs/browse/JDK-8022335||
> ||
> ||Summary of fix:||
> ||
> ||    Windows x64 binaries are built (unconditionally) with the
> equivalent of ||
> ||    -fomit-frame-pointer, so HotSpot's build-in native stack walking
> code ||
> ||    will fail to find the sender frame. As a result, hs_err on
> Windows/x64||
> ||    will always list a single frame.||
> ||
> ||    I have added the NATIVE_UNWIND_MARK macro, which on Windows/x64
> will invoke||
> ||    the StackWalk64 API to walk the stace.||
> ||
> ||Deficiency of fix:||
> ||
> ||    StackWalk64 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.||
> ||
> ||    A 'proper' implementation would be to use the the lower-level API ||
> ||    SymFunctionTableAccess64 (which reads native frame linkage info
> from the PE32+||
> ||    file header). That way we can walk both the native and Java
> frames. However, ||
> ||    as noted in the bug report, this is more complex and I will leave it||
> ||    for the future.||
> ||
> ||    As a side-fix, I also refactored a bunch of duplicated code in
> decoder.cpp into||
> ||    the DecoderLocker class.||
> ||
> ||Tests:||
> ||
> ||    JPRT||
> ||    UTE (vm.runtime.testlist, vm.quick.testlist,
> vm.parallel_class_loading.testlist)||
> ||
> ||    I also manually inserted some crashes into jvm.dll and verified
> that the ||
> ||    native stack trace is printed as expected.||
> ||
> ||
> ||Thanks||
> ||- Ioi||
> ||
> |