Community
Participate
Working Groups
I20101109-0800 Use the following snippet and place the breakpoints where indicated: public class C { public static void main(String[] args) { System.out.println(); //BP on this line System.err.println(); //BP on this line } } Steps: 1. create the class above 2. add the breakpoints as indicated 3. remove the System.out.println(); line 4. save Expected The breakpoint on the System.out.println(); would be removed Happens You are left with a breakpoint on an empty line
>3. remove the System.out.println(); line Do you deleted the TEXT or the LINE? If you only delete the text but leave the empty line, then the result is expected because - it's a line breakpoint - Debug does not verify the breakpoint locations on save
(In reply to comment #1) > >3. remove the System.out.println(); line > Do you deleted the TEXT or the LINE? If you only delete the text but leave the Just the text. > empty line, then the result is expected because > - it's a line breakpoint True, but we do not support breakpoints on blank lines. Trying to toggle a breakpoint on a blank line will result is a class load breakpoint being created for the enclosing type or another breakpoint on the next executable line (if we can determine what it is). > - Debug does not verify the breakpoint locations on save We do (see BreakpointMarkerUpdater). When the file is saved our marker updater runs the same breakpoint location verifier that is used when you toggle a breakpoint. If we expand the steps: 5. toggle the breakpoint on the blank line - it is removed [OK] 6. try to toggle it again - the breakpoint on the next executable line is toggled, resulting in the next breakpoint down being removed [OK] 7. try to toggle the blank line again - breakpoint created next line down [OK] Also note that if you debug the snippet with the breakpoint on the blank line, it will not be installed, nor will it suspend execution.
>> - Debug does not verify the breakpoint locations on save >We do (see BreakpointMarkerUpdater). When the file is saved our marker updater >runs the same breakpoint location verifier that is used when you toggle a >breakpoint. Are you 100% sure? I tested older releases back to 1.0 and that never worked. Also, you can add a method breakpoint, change "void" to "vod" and save ==> breakpoint is still there even though you can't add one.
(In reply to comment #3) > >> - Debug does not verify the breakpoint locations on save > >We do (see BreakpointMarkerUpdater). When the file is saved our marker updater > >runs the same breakpoint location verifier that is used when you toggle a > >breakpoint. > Are you 100% sure? Yes - since 3.3 we have had a marker updater that uses ValidBreakpointLocationLocator (the location finder / verifier for toggling breakpoints) to update breakpoints when you save the editor. > I tested older releases back to 1.0 and that never worked. Pre 3.3 this would not have worked. > Also, you can add a method breakpoint, change "void" to "vod" and save ==> > breakpoint is still there even though you can't add one. This sounds like another issue with the updater. I am guessing the AST still says that it is a MethodDeclaration, so we consider the location to be OK. I tested this assumption by using the snippet and changed 'public static void' to be 'pub static void' and I could still toggle a method breakpoint on the line.
> > Are you 100% sure? > Yes - since 3.3 we have had a marker updater that uses > ValidBreakpointLocationLocator (the location finder / verifier for toggling > breakpoints) to update breakpoints when you save the editor. > > I tested older releases back to 1.0 and that never worked. > Pre 3.3 this would not have worked. I tried 3.3, 3.4, 3.5, 3.6 and latest 3.7 build: it never worked. Also, commenting out code with breakpoints doesn't update (remove them). Can you give me an example where that validator actually does something? ;-)
(In reply to comment #5) > > > Are you 100% sure? > > Yes - since 3.3 we have had a marker updater that uses > > ValidBreakpointLocationLocator (the location finder / verifier for toggling > > breakpoints) to update breakpoints when you save the editor. > > > I tested older releases back to 1.0 and that never worked. > > Pre 3.3 this would not have worked. > I tried 3.3, 3.4, 3.5, 3.6 and latest 3.7 build: it never worked. Also, > commenting out code with breakpoints doesn't update (remove them). Can you give > me an example where that validator actually does something? ;-) I'm not sure what to tell you. If you put a breakpoint in jdt.debug.ui.BreakpointMarkerUpdater#updateMarker, edit and save a file that has breakpoints in it, it will be called to update the breakpoints. I did find on a few cases that even after the markers have been updated the breakpoint did not move in the editor. For example: public class Update { public static void main(String[] args) { System.err.println("foo"); //BP here } } If you remove the text from the line and save, the BreakpointMarkerUpdater runs and the location of line 4 is found (the closing '}') [OK], but after updating the marker it does not move in the editor, the breakpoint stays on line 3 (the syserr line) [BAD]. This makes this bug all the more relevant, if even after our updater runs breakpoints are not moved correctly.
>I'm not sure what to tell you. I guess we were just commenting on different things: you commented on the updater and I purely on what the user sees. Reading you last comment indicates that the updater runs but the breakpoint is still wrong.
OK, I quickly debugged the example from comment 6 and BreakpointMarkerUpdater.updateMarker(IMarker, IDocument, Position) is indeed called but this method does not return 'false' i.e. does not report that the marker should be deleted. Mike, I guess it's your turn now ;-)
Debugged this and found that immediately following the breakpoint marker updater running the org.eclipse.ui.texteditor.BasicMarkerUpdater runs and resets the values of the breakpoint - so it does not move. Not sure what we can do about this, since we have no control over if any other marker updaters run and what they might do. Perhaps the best approach, rather than trying to move the breakpoint, would be to delete it and recreate it at the new location.
This never worked, hence I wouldn't touch any updater code at this point. Suggest to move to 3.8.
> Suggest to move to 3.8. I agree
*** Bug 348374 has been marked as a duplicate of this bug. ***
*** Bug 356281 has been marked as a duplicate of this bug. ***
I don't want to change this so late in M7. Moving to 4.3
Sometime BasicMarker Updater executes after the JDT Breakpoint Marker Updater and moves the line back. Created bug 44052 in platform.text to make sure that that platform BasicMarkerUpdater executes first
(In reply to Sarika Sinha from comment #15) > Sometime BasicMarker Updater executes after the JDT Breakpoint Marker > Updater and moves the line back. Created bug 44052 in platform.text Bug 440952 that is.
Added dependency on basic marker updater with http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=3b45f67f439b7d57b654b868347a110126afb9fd
Resolved by commit in Comment #17
Verified using Eclipse SDK Version: Mars (4.5) Build id: N20141120-2000
