Community
Participate
Working Groups
Version: 2021-06 (4.20) Build id: I20210611-1600 When a workspace is re-used on a new Eclipse installation, it is often the case that breakpoints fail to associate with corresponding lines in the updated installation. (Same problem can occur after a file edit.) When this happens a breakpoint is retained at the original line, but no marker is shown in the left hand bar. Execution nevertheless stops there, confusingly since it isn't the updated line. Examining the breakpoint properties shows an error "Activities - RUSA does not exist" where "Activities - RUSA" is my alphabetically first "Other Projects" which happens to be closed; hence does not exist. Double clicking the bar to remove the breakpoint, does not remove the breakpoint, rather it overrides with a new correct breakpoint and bar marker. Double clicking again and the stale breakpoint is restored with no bar marker. Bug A. Please add a "Remove Breakpoint" menu entry in the stack trace to avoid the long delay loading breakpoints and then navigating in the Breakpoints View. Bug B. Please ensure that a stale breakpoint has a bar marker so that double clicking it can remove it. (Else, too hard, upgrade the stale breakpoint to the moved line.)
(In reply to Ed Willink from comment #0) > Examining the breakpoint > properties shows an error "Activities - RUSA does not exist" where > "Activities - RUSA" is my alphabetically first "Other Projects" which > happens to be closed; hence does not exist. or E:\Tools\Eclipse\4.10\plugins\org.eclipse.emf.ecore_2.16.0.v20181124-0637.jar is not on its project's build path since breakpoints in the previous installation's plugins are almost certainly not available on the new installation.
Created attachment 287238 [details] screenshot The attached screenshot shows a confusion that while giving a different user experience is almost certainly due to a bad handling of stale breakpoints. The breakpoint properties shows a breakpoint at line 1780 in PivotMetamodelManager.installPropertyDeclaration(Property) The editor shows that line 1780 is now part of installLibraryContents(Library) hence the breakpoint is stale explaining its non-display in the vertical decorator bar. The debugger shows that execution did stop at line 1780 in installLibraryContents(Library) which is confusing since that is a stale location and the breakpoint cannot be cleared by double clicking in the vertical bar.
Suggestion 1: using the existing breakpoint memento Any breakpoint is either viaable or stale according to whether a consistent marker can be shown in an editor vertical bar. If stale, the breakpoint should be shown crossed out in the Breakpoints View, possibly re-using 'deprecated' icons, and the breakpoint should be ignored during execution. (A remove all stale breakpoints menu action would be nice.) Suggestion 2: adjusting the breakpoint memento Rather than the breakpoint being at file line X member Y, let the breakpoint be at member Y start plus offset Z, allowing the breakpoint to better track its location after edits, only going stale if beyond the end of the declaration, at which point Suggestion 1 applies.
It is very irritating for me as well, will try to put some time but if someone wants to put some effort, it will be most welcome.
Sadly, as evidenced by the many breakpoint bugs I have raised recently, JDT has been subject to severe bit rot in this area. Worst of all is the hard to reproduce breakage of Ctrl-Z in editors that have been used by the debugger, closely followed by the loss of helpful completion assist when the debugger knows better and the focus stealing when an out of focus incremental compiler decides it is more important than my editing.
(In reply to Ed Willink from comment #5) > Sadly, as evidenced by the many breakpoint bugs I have raised recently, JDT > has been subject to severe bit rot in this area. Worst of all is the hard to > reproduce breakage of Ctrl-Z in editors that have been used by the debugger, > closely followed by the loss of helpful completion assist when the debugger > knows better and the focus stealing when an out of focus incremental > compiler decides it is more important than my editing. You know that we all are working hard with limited resources. These kinds of comment will not motivate us to put an extra effort.
Will be looking at the related bugs in 4.23.
Will be handled via https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/55
