RFR (S) 8022335 - (round 2) Native stack walk on Windows x64
Zhengyu Gu
zhengyu.gu at oracle.com
Fri Aug 30 05:28:38 PDT 2013
Hi Ioi,
src/os_cpu/windows_x86/vm/os_windows_x86.cpp
493 if (fp == NULL) {
494 return frame();
495 }
probably you want to move it outside #ifdef AMD64. It is not platform
specific, right?
Other than that, looks good to me.
FYI:
You can use "CrashGCForDumpingJavaThread" flag to cause JVM to crash.
Thanks,
-Zhengyu
On 8/29/2013 6:37 PM, Ioi Lam wrote:
> Please review this fix:
>
> http://cr.openjdk.java.net/~iklam/8022335/win64_stack_walk_002/
>
> 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://bugs.openjdk.java.net/browse/JDK-8022335
>
> What's new:
>
> The code is much more simplified than my last version. All
> interesting
> code is in a single function -- os::platform_print_native_stack
> in os_windows_x86.cpp. The rest is just busy work.
>
> 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 os::platform_print_native_stack() function for
> Windows/x64 only. It uses the StackWalk64 API to walk the stace.
>
> Because the Win/x64 frame layout is very different than what
> HotSpot expects,
> I decided to implement os::platform_print_native_stack() as a
> completely
> stand-alone function, and do not interact with the existing
> "frame" C++ class.
> See comments in os_windows_x86.cpp for details.
>
> 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.
>
> Printing the Java frames *may* be possible. However, at this
> point, I want
> to keep the code simple and crash proof. I will file a different
> bug for
> printing the Java frames.
>
> Bonus:
>
> As a side-fix, I 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 on Win/x64.
>
>
> Thanks
> - Ioi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130830/f85b186a/attachment.html
More information about the hotspot-runtime-dev
mailing list