Community
Participate
Working Groups
Bug 82503 was closed because the "Later." field is no longer supported. I'm re-opening and adding the multi-threaded case. The fact that RunToLine uses "skip all breakpoints" means that a long running RunToLine will disable all breakpoints, not only for the relevant thread, but for all threads, and all targets. So, if I have two threads running and I do a runToLine in one of them, any breakpoint hit in the other thread during the runToLine operation will be skipped. I realized it is a rare case, but I think it makes breakpoints hard to trust when using runToLine. I was thinking that the BreakpointManager could allow to skip breakpoints based on a debug context; that way, only breakpoints of a particular thread could be skipped/disabled when doing a runToLine. I don't know if the java debugger allows for this. If the debugger does not allow this, then another possibility would be not to use the "skip breakpoint" feature and instead, to automatically resume a thread that stopped before its runToLine operation completed. This latter solution is what we had to implement in the CDT-DSF debugger.
Run to line implementation is specific to JDT.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
