getPCDescNearDbg returns incorrect PCDesc

[David Griffiths]

Hi Jc, ok thanks, I'll see if I can come up with a simple example.

Cheers,

David

On Wed, 16 Jan 2019 at 17:30, JC Beyler <jcbeyler at google.com> wrote:

> Hi David,
>
> The explanation you are providing is clear to me, though I'm not sure at
> all what the right fix would be in this case. I would agree that there
> might be a bug here but it would be easier to see if you could provide an
> easy reproducer that shows how the initial line is off by 1 and then how it
> messes up higher in the stack if you try to fix it by your -1.
>
> My best guess is that there is a difference between code paths as you are
> saying and we might have to differentiate top frame and other frames for
> this calculation but without a reproducer to see it in action, it is hard
> to tell.
>
> Thanks,
> Jc
>
> On Wed, Jan 16, 2019 at 7:58 AM Doerr, Martin <martin.doerr at sap.com>
> wrote:
>
>> Hi David,
>>
>> re-posting to serviceability mailing list since you're referring to a
>> method from
>>
>> https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html
>>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
>> David Griffiths
>> Sent: Mittwoch, 16. Januar 2019 12:08
>> To: hotspot-dev at openjdk.java.net
>> Subject: getPCDescNearDbg returns incorrect PCDesc
>>
>> Hi, I'd like some help please understanding what appears to be a bug in
>> getPCDescNearDbg. The problem is caused by the fact that the _pc_offset
>> value stored in a PcDesc is actually the offset of the code contained in
>> the _next_ PcDesc rather than the current one. I assume it's done like
>> this
>> so that obtaining stack traces works correctly. At least on x86, the last
>> instruction in a PcDesc chunk is the callq which means that the return
>> address pc points to the next PcDesc. Therefore associating the PcDesc
>> containing the callq with the address of the next PcDesc chunk means that
>> the matching works in getPCDescAt.
>>
>> But this causes "off by one" errors in getPCDescNearDbg which appears to
>> expect the PcDesc getRealPC address to be that of the PcDesc itself rather
>> than the following one. So you sometimes see incorrect top of stack line
>> numbers when debugging. (And this would presumably also affect profilers).
>>
>> I can fix the top of stack issue by changing distance to:
>>
>> long distance = pcDesc.getRealPC(this).minus(pc) - 1
>>
>> but this then messes up the line numbers further down the stack because
>> they are trying to match against return pcs.
>>
>> Anybody come across this before, is my analysis correct?
>>
>> Cheers,
>>
>> David
>>
>
>
> --
>
> Thanks,
> Jc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190117/81e5df6b/attachment.html>