[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    When javaFrameAnchor::_last_Java_sp == NULL for a non-first entry frame
From:       yamauchi () google ! com (Hiroshi Yamauchi)
Date:       2009-11-20 19:51:29
Message-ID: d6262f010911201151y2e614670u3c68ab6016c3a7dd () mail ! gmail ! com
[Download RAW message or body]

+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
>>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]