Summary: | Stale Breakpoint Confusion | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Ed Willink <ed> | ||||
Component: | Debug | Assignee: | Sarika Sinha <sarika.sinha> | ||||
Status: | ASSIGNED --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | sarika.sinha | ||||
Version: | 4.16 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows 10 | ||||||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=354784 https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/55 https://bugs.eclipse.org/bugs/show_bug.cgi?id=451210 |
||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Ed Willink
2021-09-22 11:39:45 EDT
(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 |