RFR: 8006423 SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67)

[Staffan Larsen]

Thanks David!

/Staffan

On 1 feb 2013, at 06:05, David Holmes <David.Holmes at oracle.com> wrote:

> Hi Staffan,
> 
> First, please refrain from doing code cleanup (long line reformatting) alongside a fairly significant change - it makes the true changes harder to spot. Thanks.
> 
> Based on our discussions this all looks good to me.
> 
> Thanks,
> David
> 
> On 18/01/2013 5:48 AM, Staffan Larsen wrote:
>> This is a request for review of a fix for SA on OS X.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8006423/webrev.00/
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006423
>> 
>> The bug report contains a detailed description of the problem and the proposed solution. I have copied some of that text below. To verify the fix I have manually run jstack on OS X.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> 
>> In many cases when running the SA version of JStack (or other SA tools) an NPE is thrown in BsdThread.getContext(). The underlaying cause is that SA fails to read the context of the thread in the native method getThreadIntegerRegisterSet0() (thread_get_state returns an error).
>> 
>> The following is my understanding of what the cause is and a suggestion for a fix - my experience with OS X is a bit limited so I may be off on some details.
>> 
>> thread_get_state() takes a thread_t as a parameter. The value of this parameter comes from SA reading the value of the OSThread._thread_id field in the Hotspot process being debugged. This value is set in HotSpot to ::mach_thread_self() which is documented as "The mach_thread_self system call returns the calling thread's thread port."
>> 
>> My theory is that this "thread port" in not valid when a different process calls thread_get_state(). Instead, the other process (SA in this case) needs it's own "thread port" for the thread it wants to access.
>> 
>> There is a way to list all the thread ports in a different process (or "task" as they are called in Mach) via the task_threads() function.
>> 
>> So now we have the thread ports, we just need to correlate them with the C++ Thread objects in the Hotspot process. One way to do this correlation is via the stack pointer. We can get the current value of the stack pointer (rsp) in SA and look through all the Thread objects to see which one the stack pointer belongs to (by looking at Thread._stack_base and Thread._stack_size).
>> 
>> Another way seems to be to use the thread_info() function with the THREAD_IDENTIFIER_INFO parameter. This gives us a struct which has a field called thread_id. The comment for this field in the thread_info.h file says "system-wide unique 64-bit thread id". The value for this thread_id is the same when called from Hotspot and when called from the debugging process (SA), so this looks like a way to do the correlation.
>> 
>> This requires Hotspot to store this value in OSThread and SA to first list all the "thread ports", then find the thread_id for each one and select the right "thread port" for the thread we are looking for.
>> 
>> Using a thread_id provided by the system seems more reliable than using the stack pointer for correlation.
>> 
>>