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