getPCDescNearDbg returns incorrect PCDesc

[JC Beyler]

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/20190116/93cb19ac/attachment.html>