RFR 8163127: Debugger classExclusionFilter does not work correctly with method references

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Tue Jan 22 21:41:03 UTC 2019


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
>
>




More information about the serviceability-dev mailing list