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 <jcbey...@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.do...@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-boun...@openjdk.java.net> On Behalf Of >> David Griffiths >> Sent: Mittwoch, 16. Januar 2019 12:08 >> To: hotspot-...@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 >
