Bug 487998 - Editing code while debug is active causes breakpoints to move unexpectedly
Summary: Editing code while debug is active causes breakpoints to move unexpectedly
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug-dsf-gdb (show other bugs)
Version: 9.0.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Jonah Graham CLA
QA Contact: Marc Khouzam CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-18 05:42 EST by Jonah Graham CLA
Modified: 2016-04-27 09:38 EDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonah Graham CLA 2016-02-18 05:42:58 EST
Under normal conditions if you edit some code, Eclipse tries to keep markers (such as breakpoints) on the same logical line of code.

For example if I have a breakpoint on the "if" in this piece of code:

volatile int i = 0;
int main(void)
{
    while (1) {
    	i++;
    	i++;
    	if(i > 10000) i = 0;
    }
  return 0;
}

and then I delete the two lines with "i++", the breakpoint continues to point to the "if" line, as expected.

However, if you happen to make the same edit while the debugger is connected, then the breakpoint is initially moved to the "if" line as expected. But when you terminate the debug session the breakpoint is relocated to its original line number, which means it now points (unexpectedly) at the "return" line.
Comment 1 Jonah Graham CLA 2016-02-18 05:43:27 EST
I am looking at this issue.
Comment 2 Jonah Graham CLA 2016-02-18 08:35:22 EST
This is happening because of the features added in Bug 360280. 

In that bug when a breakpoint is fully uninstalled (decrementInstallCount decrements fInstallCount to 0), AbstractLineBreakpoint.resetInstalledLocation() is called. This repositions the breakpoint from the current line to the "REQUESTED_LINE", which is the line number it was originally planted on. 

The problem is that resetInstalledLocation assumes that any change to the LINE_NUMBER attribute must have come because of repositioning the breakpoint based on GDB information. However, platform updates the line number based on the edits made in the editor.
Comment 3 Jonah Graham CLA 2016-03-27 15:48:26 EDT
One possible solution to this is to add a flag/condition that only causes the breakpoint to be moved back if org.eclipse.cdt.debug.internal.core.breakpoints.AbstractLineBreakpoint.setInstalledLineNumber(int) has been called to move the breakpoint in the first place. At the moment, the breakpoint property page is the only thing calling setInstalledLineNumber, and that is in part an error (perhaps in the API exposed) AFAICT. Alternatively such a flag could be set if REQUESTED_LINE and LINE_NUMBER differed.

By using such a flag, the functionality can remain for CDT extenders who use it, without affecting those that don't.
Comment 4 Eclipse Genie CLA 2016-03-28 11:45:27 EDT
New Gerrit change created: https://git.eclipse.org/r/69374
Comment 5 Stefan Sprenger CLA 2016-04-04 06:18:58 EDT
This bug contains two different issues.

1.) If you save the edit while the debugger is connected and terminate the debug session.

2.) If you don't save the edit and just terminate the debug session.

Both lead to a misplaced Breakpoint. Number 1 is resolveable like Jonah suggested before. I'm currently looking on number 2, which seems to be more tricky.
Comment 7 Jonah Graham CLA 2016-04-27 09:38:49 EDT
(In reply to Stefan Sprenger from comment #5)
> This bug contains two different issues.
> 
> 1.) If you save the edit while the debugger is connected and terminate the
> debug session.
This bug and associated fix is for this issue.


> 
> 2.) If you don't save the edit and just terminate the debug session.
Bug 490996 covers this issue.