Yes, I will have a look at it tomorrow.
Chris
On 1/22/19 1:41 PM, [email protected] wrote:
Hi Daniil,
It'd be nice if Chris has a chance to look at this fix.
He has most recent experience in this area.
Thanks,
Serguei
On 1/17/19 6:08 PM, Daniil Titov wrote:
Please review the change that fixes JDB stepping issue for a specific
case when the single step request was initiated earlier in the stack,
previous calls were for methods in the filtered classes (single
stepping was disabled), handleMethodEnterEvent() re-enabled stepping
and the first bytecode upon entering the current method requires
resolving constant pool entry. In this case the execution resumes in
java.lang.Classloader.loadClass() and since it is also a filtered
class the single stepping is getting disabled again (stepControl.c
:593). When loadClass() exits a notifyFramePop() is called on the
loadClass() frame but due to condition fromDepth >= afterPopDepth at
stepControl.c :346 (that doesn't hold in this case, in this case
fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to
enable single stepping back. The fix removes the excessive condition
fromDepth >= afterPopDepth in notifyFramePop() method
(stepControl.c:346) to ensure that when a method cal!
led from the stepping frame (and during which we had stepping
disabled) has returned the stepping is re-enabled to continue
instructions steps in the original stepping frame.
Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01
Bug: https://bugs.openjdk.java.net/browse/JDK-8163127
Thanks!
--Daniil
