RR 6313816: SA: jstack -m fails on Win32 : UnalignedAddressException

[Peter Allwin]

Hi Kevin,

Looks good!

I've been looking into improving the quality of native stack traces on 
Windows using IDebugControl::GetStackTrace. This has the advantage of 
handling some FPO frames on x86 (a common source of these exceptions), 
as well as supporting AMD64 (walking the stack using RBP does not work 
at all on Windows/X64). There are still some issues to iron out before 
this change is ready, but your fix is a good start to what I'd like to 
accomplish.


Thanks,

Peter

> ------------------------------------------------------------------------
>
> 	Kevin Walls <mailto:kevin.walls at oracle.com>
> Tuesday, April 30, 2013 7:02 PM
>
>
> Hi,
>
> I'd like some review of this suggestion to fix:
> 6313816 SA windows unaligned address exception
>
> webrev:
> http://cr.openjdk.java.net/~kevinw/6313816/webrev/
>
> This bug is a long-standing annoyance, mainly shown by using jstack -m
>
> Already fixed on Linux with additional sanity checks on ebp/rbp values in
> e.g. LinuxX86CFrame.sender()
>
> On Windows there isn't such a convenient place to put these checks, as 
> they
> call getAddressValue() which is only part of the specific debugger 
> interfaces
> such as LinuxDebugger, WindbgDebugger, etc.. and on Windows we use
> X86CFrame and AMD64CFrame.  These are constructed with only a
> CDebugger, there is no "WinXXXFrame" class - perhaps there should be!
>
> That's what  I've tried here, by renaming e.g. X86CFrame to WinX86CFrame,
> and adding the extra sanity checks as we already have in LinuxX86CFrame.
>
> As files have move thed diff isn't obvious, but in common with some 
> previous changes
> the new bits are x86 and x64 versions of these:
>
> + // Check alignment of rbp
> + if ( dbg.getAddressValue(rbp) % ADDRESS_SIZE != 0) {
> + return null;
> + }
> +
>
> and
>
> - if (nextRBP == null) {
> + if (nextRBP == null || nextRBP.lessThanOrEqual(rbp)) {
>
>
> This additional symmetry between the platforms seems to make sense, and
> should help any future changes.
>
> Thanks
> Kevin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130502/ef254309/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130502/ef254309/compose-unknown-contact.jpg