Community
Participate
Working Groups
Created attachment 278481 [details] Video showing the problem with the reproduction steps from the bug description. Reproduction steps: 1. Open the snippet below as a Java source in a Java project. 2. Set breakpoints at lines 8 and 9. 3. Navigate the cursor to line 8, Ctrl+Alt+Up arrow. 4. Navigate the cursor to line 10 (of the modified source), Ctrl+Alt+Up arrow. 5. Alt+Up arrow. 6. Set breakpoint at line 9 (of the modified source). 7. Observe that one of the breakpoints set in step 2. is gone, and that there is no new breakpoint. public class SuspendedThreadNotShown { public static void main(String[] args) throws InterruptedException { sleep(500); new Thread(() -> { for (int i = 0; i < 10; ++i) { sleep(500); System.out.println("set a breakpoint here"); } }).start(); System.out.println("set a breakpoint here"); } private static void sleep(long ms) { try { Thread.sleep(ms); } catch (InterruptedException e) { // } } } Seen with: Eclipse SDK Version: 2019-06 (4.12) Build id: I20190402-1800 RHEL 7.4 GTK 3.22 We have also seen this with 4.10 and maybe 4.9. No idea about earlier versions.
File edit "moves" old breakpoint to the line 14, where previously no code existed, so the old breakpoint seem to be removed because it points into nirvana in the generated class file. I've not seen the code where it is implemented, but I guess the check for the new breakpoint triggers validation for the old one too. I have no idea how this validation is working at all for the file buffer which is not yet compiled to the valid bytecode? Or does it look at the editor AST to check valid BP location? If the check works for compiled (saved) code only, checks on unsaved editor simply "occasionally" work.
You may want to see org.eclipse.jdt.internal.debug.ui.actions.ToggleBreakpointAdapter You can also find some discussions on Bug 310478.
I'm looking into some (very rare) sporadic failure in our ARTs that includes xtext + JDT interactions. A cache in JavaModelManager seems to behave oddly, but its hard to pinpoint why and how. I'm setting a lot of breakpoints in JavaModelManager, on different places where its caches are manipulated. Then I'm adding extra system outs for debug purposes. Every time I copy or move code around with Alt+Arrow or Ctrl+Alt+Arrow (up or down arrow), some of my breakpoints get moved. This is extremely frustrating, since I have to repair the breakpoint (and remember which ones I need). I've pinged Andrey to schedule this for near future fixing, its an extremely frustrating bug once you start running into it.
In particular my breakpoints are on System.out lines added by me, and get moved to other System.out statements that already present in JavaModelManager...
*** Bug 559752 has been marked as a duplicate of this bug. ***
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.
Unfortunately it's still there. I looked at it and problem is these copying and moving up of lines is not handled for breakpoints and the breakpoint markers are not in synch with the editor. So when finally we try to add a breakpoint at line number 8/9, it finds an existing breakpoint and removes it.
