Community
Participate
Working Groups
I20100425-2000, same in 3.5.2 (M20100211-1343) - new workspace - check out org.eclipse.core.expressions from HEAD - open type ExpressionConverter - show line numbers - set a line breakpoint at line 157 - show CVS history for file - on rev. 1.14, choose context menu > Get Contents => breakpoint in ruler moves to line 160, but Breakpoints view still talks about line 157. - doubleclick breakpoint in ruler to remove it => does not remove the shown breakpoint, but toggles a new breakpoint at line 160
*** Bug 324428 has been marked as a duplicate of this bug. ***
Still happens frequently for me when I have line breakpoints in a file and then update the file contents via EGit's Pull or Replace With > ... . => Breakpoint becomes stale, and I have to open the Breakpoints view to delete it
Steps in master with EGit: - clone git://git.eclipse.org/gitroot/platform/eclipse.platform.runtime.git - import org.eclipse.core.expressions - check out ddc544b226d5cbe4ad864f0a9b7b4b1f4943b45a - open type ExpressionConverter - set a line breakpoint at line 157 - context menu > Replace With > Commit... - select commit 5f0e18d (Updated copyright date) => in the editor, the breakpoint moved to line 160 Bugs: => double-clicking line 160 creates another breakpoint instead of removing the existing one => double-clicking line 157 deletes the breakpoint shown at line 160 To debug, you can make the breakpoint range visible via Preferences > Annotations, where you can select annotation type "Breakpoint" and e.g. select "Show in > Text as > Dashed Box". The problem is that the offset and length of the marker in the document has not been adjusted and is now out of sync with the line number. The Toggle Breakpoint action should be aware that the editor uses offset/length and not the line number of the Marker. Therefore, the action also needs to calculate the line number from the offset. Once that's fixed, it will find the stale breakpoint and let the user delete or edit it.
Thanks Markus, I will work on this.
New Gerrit change created: https://git.eclipse.org/r/90902
(In reply to Eclipse Genie from comment #5) > New Gerrit change created: https://git.eclipse.org/r/90902 Even though the problem statement in this and bug 255425 looks different, solution looks common. I have tried to replace the line breakpoint checking algorithm to check the annotation marker position and compare the line number. Two points to think is : 1. By this change we can remove the stale breakpoint at line 160 from c#3 but if we double click on line 157, it will still remove the breakpoint from line 160( I am hoping it is ok). This also removes the breakpoint defined in Bug 255435. 2. Right now I have replaced the line breakpoint check to go to annotation markers, If there are many no breakpoint markers, it might e un necessary for normal cases. So we can also think of first checking using line breakpoint exists, if not found use annotation markers to find the line no.
Will release in early stage of M7.
Gerrit change https://git.eclipse.org/r/90902 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=3054d758448a370f65e828790503c936b1193da4
