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

[JC Beyler]

Hi Daniil,

I "think" I understand what  is  going  on but my major comment will be
that you might want to revisit the comments and the log.

The comment under the test:
 300         if (step->depth == JDWP_STEP_DEPTH(OVER)) {

might need a bit of a change.

But more importantly,
347              * We installed a method entry event handler as part of a
 348              * step into operation. We've popped back to the original
 349              * stepping frame without finding a place to stop.
 350              * Resume stepping in the original frame.
 351              */
 352             LOG_STEP(("handleFramePopEvent: starting singlestep, have
methodEnter handler && depth==OUT && fromDepth >= afterPopDepth
(%d>%d)",fromDepth, afterPopDepth));

That comment might also need a bit of a  rewrite due to "without finding a
place  to stop", is that still true or was it  supposed that this was true
due to the comparison you removed.

Finally the message in the LOG_STEP needs to change since the comparison is
no longer there, no?

Thanks,
Jc

On Thu, Jan 17, 2019 at 6:09 PM Daniil Titov <daniil.x.titov at oracle.com>
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
>
>
>

-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190117/a3609062/attachment.html>