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
