Community
Participate
Working Groups
Created attachment 281848 [details] Video showing the problem, following the steps from the description. To reproduce: 1. Debug Eclipse. 2. Debug a simple snippet with a breakpoint from the debuggee Eclipse: public class Test { public static void main(String[] args) { System.out.println(); // set a breakpoint here } } 3. Select the debug target in the Debug view ("Test at localhost:...), observe the suspend button in the main toolbar is enabled. 4. Select the suspended stack frame, observe the suspend button is disabled. 5. Set a breakpoint at "return false;" in "org.eclipse.debug.internal.core.commands.ForEachCommand.isExecutable(Object[], IProgressMonitor, IEnabledStateRequest)". 6. Select the debug target in the debuggee Eclipse again. 7. Select the suspended stack frame again. 8. Observe 2 breakpoint hits for the breakpoint from step 5. 9. Resume the breakpoint hit for the debug target, then resume the breakpoint hit for the stack frame. 10. Observe that the Debug view has selection on the debug target, but the suspend button is disabled (as if the stack frame was selected). We observe this with Eclipse 4.12, I can reproduce this with latest Platform/JDT (see attached video "suspend_button_update_problem.mp4").
If I replace the result of org.eclipse.debug.core.commands.AbstractDebugCommand.getEnabledStateSchedulingRule(IDebugCommandRequest) with an exclusive rule, the problem is gone. Looking at the Java doc of the method this is public API. We probably need to change the current behaviour in some way.
I'm not sure an exclusive rule is the perfect fix. Is the order in which the scheduled jobs are executed reliable? Another solution might be to not spawn a job for each enablement update. Instead queue the requests, schedule one job and process all pending requests in correct order.
New Gerrit change created: https://git.eclipse.org/r/157900
(In reply to Paul Pazderski from comment #2) > I'm not sure an exclusive rule is the perfect fix. Is the order in which the > scheduled jobs are executed reliable? It seems so. > Another solution might be to not spawn a job for each enablement update. > Instead queue the requests, schedule one job and process all pending > requests in correct order. Is this different to the rule? I think both kind of trample the initial concept of AbstractDebugCommand.getEnabledStateSchedulingRule().
Ah, with the change I understand what you meant with public API. I missed the scheduling rule methods in AbstractDebugCommand.
(In reply to Simeon Andreev from comment #4) > Is this different to the rule? I think both kind of trample the initial > concept of AbstractDebugCommand.getEnabledStateSchedulingRule(). It might be less overhead but if the job execution is ordered the scheduling rule is fine and (what I missed) already intended in this command framework.
I was not able to reproduce the problem exactly on Mac, but I do see a better scheduling rule after the change. I will be testing it on Windows to confirm.
(In reply to Simeon Andreev from comment #0) > 9. Resume the breakpoint hit for the debug target, then resume the > breakpoint hit for the stack frame. > 10. Observe that the Debug view has selection on the debug target, but the suspend > button is disabled (as if the stack frame was selected). On Windows and Mac, behaviour is little different. I have to disable all breakpoints and after resuming in the order, the selection remains on StackFrame and button disabled. But If I don't disable the breakpoint, the breakpoints keep hitting for couple of times for different commands. After the patch this is more consistent. @Andrey, Did you get a chance to test it?
I don't see any disadvantage of putting this change. If the change helps on Linux, it is good to go.
Gerrit change https://git.eclipse.org/r/157900 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=95ce1d5900ef6e4e4aafb1d0c0220cdcd2413f52
