Community
Participate
Working Groups
RC3a When suspended at a breakpoint during an evaluation (for example, in the scrapbook or from the display view), the step actions are disabled.
Marking as RC4 candidate. The problem is in JDIThread#canStep(). Currently we disallow stepping if an evaluation is being performed. However, I beleive this was to protect when a user is performing rapid stepping and implicit evaluations are being performed. We should be able to specialize the test to disallow stepping only when the evaluation being performed is implicit (and allow stepping during explicit evaluations).
In fact, we should not discriminate between explicit/implicit evaluations. A user may also suspend an implicit evaluation, and be able to step.
Here is my proposed fix to JDIThread. Rather than disallowing the step if an evaluation is in progress, disallow stepping if there is a queued runnable yet to execute. This allows stepping to occurr whenever the thread is suspended (except when quietly suspended and evaluating a conditional breakpoint), and all async evaluations are complete. Here is the proposed replacement method for #canStep(). protected boolean canStep() { try { return isSuspended() && !isSuspendedQuiet() && (fAsyncThread == null || fAsyncThread.isEmpty()) && !isStepping() && getTopStackFrame() != null && !getJavaDebugTarget().isPerformingHotCodeReplace(); } catch (DebugException e) { return false; } } I'd like to have John W and Luc B "evaluate" the proposed fix.
Risk is moderate - I say this because the stepping code is heavily used. However, I am confident with the fix. The fix is more robust than the previous code, since with the old code it was possible to request a step while in a suspended state, but while evaluations were queued.
This is a regression from 2.0 (changed sometime during the 2.1 development cycle). In 2.0, users were able to step within an evaluation.
+1
Released fix to HEAD. Please verify, Luc.
Please verify.
Verified.
