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

[Chris Plummer]

Yes, I will have a look at it tomorrow.

Chris

On 1/22/19 1:41 PM, serguei.spitsyn at oracle.com 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
>>
>>
>
>