When javaFrameAnchor::_last_Java_sp == NULL for a non-first entry frame
Hiroshi Yamauchi
yamauchi at google.com
Fri Nov 20 11:51:29 PST 2009
+serviceability-dev since this is related to AsyncGetCallTrace
Xiaobin,
Thanks for the info. I believe you are referring to the comment around
line 580. Having looked at it, I'm not sure about the connection
between that and this issue (since both of the Linux environments are
fairly modern (NPTL)).
My issue is that the javaFrameAnchor inside the JavaCallWrapper which
is stack allocated in a non-first entry frame has its last_Java_sp ==
NULL, observed from AsyncGetCallTrace (the profiler) for an unknown
reason. It could be a bug or a change of the invariant.
Thanks,
Hiroshi
On Thu, Nov 19, 2009 at 6:42 PM, Xiaobin Lu <Xiaobin.Lu at sun.com> wrote:
> I don't think I know why _last_Java_sp is NULL. However, to explain why you
> saw different stack pointer value on different Linux environment, take a
> look at os_linux.cpp, there are about 40 lines of comments talking about
> "thread stack" related things on different Linux implementations.
>
> -Xiaobin
>
> On 11/19/09 18:10, Hiroshi Yamauchi wrote:
>>
>> Hi,
>>
>> In AsyncGetCallTrace, I observe
>>
>> javaFrameAnchor::_last_Java_sp == NULL
>>
>> in non-first entry frames on Linux/x86. It is the condition for the
>> entry frame to be a first frame. So, I get truncated stack traces
>> because stack walk stops at the false first frame.
>>
>> I thought that the contract was that the _last_Java_sp != NULL for all
>> non-first entry frames. Is it correct?
>>
>> Strangely I see the behavior on one Linux environment (kernel, libc,
>> other libraries) but not on another Linux environment (Ubuntu). But
>> I'm not sure how the environment could affect the _last_Java_sp field.
>>
>> Does it ring anyone's bell?
>>
>> thanks.
>>
>> Hiroshi
>>
>
>
More information about the serviceability-dev
mailing list