Request for review: 6310967: SA: jstack -m produce failures in output

[Poonam Bajaj]

Hi David,

On 6/13/2012 7:35 AM, David Holmes wrote:
> Hi Poonam,
>
> It seems to me that rather than passing the ThreadProxy through to 
> f.sender the frame, which has to be a frame of some thread, should 
> already know what that thread is and so be able to access it directly.
>
> In other words: shouldn't each CFrame maintain a reference to the 
> thread it corresponds to?

Yes, it would have made more sense to have a reference of ThreadProxy in 
the Frame classes. But that requires restructuring of lot more code. All 
the Debugger classes (e.g. 
agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java) 
also need to be touched that have the topFrameForThread() where we 
create the first frame for the thread.

This fix was mainly for 6uxx and it didn't seem reasonable to me to 
restructure and touch too many classes for this simple fix.

Thanks,
Poonam

>
> David
>
> On 12/06/2012 11:05 PM, Poonam Bajaj wrote:
>> Hi,
>>
>> Please review this fix for bug 6310967
>> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6310967>.
>>
>> 6310967 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6310967>:
>> SA: jstack -m produce failures in output
>>
>> http://cr.openjdk.java.net/~poonam/6310967/webrev.00/
>>
>> Problem: jstack -m fails with UnalignedAddressException.The problem is
>> that while finding the caller frame of a frame in sender() method, we
>> don't check the validity of the frame pointer (rbp / ebp).
>>
>> These changes add a simple check that the frame pointer(rbp) should be a
>> valid pointer on the stack by making sure that it is not less than the
>> stack
>> pointer(rsp).
>>
>>
>> Thanks,
>> Poonam
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120613/8dde6f4e/attachment-0001.html