Version: CVS (using KDE Devel) Installed from: Compiled sources Set a breakpoint run the debugger until you hit it. now use the editor to add some lines above it. Note that as the lines are added the breakpoint line number is adjusted to account for the additional lines. The problem is that is I have a bp on line 100 and add a line of text above it, pushing line 100 to become line 101. I end up with a bp on both lines 100 and 101. Add four lines, get four extra bp's. The only happens if the debugger is running.
I can see the same here. When editing files with a lot of breakpoints I wind up with huge numbers of breakpoints clustered around the original ones.
Goodness me! Something is very broken here. On entering blank lines above a breakpoint it seems to work - but then Exit kdevelop start kdevelop breakpoints don't appear (they used to) expand breakpoint widget disable and re-enable a bp - the breakpoint appears (good) add a couple more Try and enter several blank lines above the first bp - focus ends up in the bp widget after the first blank line! (Although I'm not sure that's always true) and with gdb running enter some blank lines above a bp - well that seems to work :-) Now Ctrl-Z to remove those blank lines the icon bar lights up with bp's Well... kdevelop cvs (from 17th May 2004) qt-3.3.2 Who would like to take a look into this?
I already took a brief look at it (I guess I should have confirmed it.) It's not a trivial thing to solve at all. I'm not even sure it can be solved. The solution could be expected to be to listen to KTextEditor::MarkInterface::marksChanged() only when the debugger is not running, and KTextEditor::MarkInterfaceExtension::markChanged() when it is. The problem with this is that markChanged() (which is emitted when a mark is added or removed) won't give us sensible results unless we also track marksChanged() (which is emitted at any mark change, such as the moving of marks as a result of inserting lines) (The breakpoints widget would need to know that the mark just removed from line 6 is in fact the mark that used to be in line 4, and tell this to the debugger.) A further problem is that the breakpoints widget is generic and doesn't know either which debugger it frontends for the moment, or if this debugger is currently running. Now, the thing is, we don't really want to both have breakpoints in running code and edit it at the same time. The debugger can't be expected to step correctly through nonrunning code no matter how smart we attempt to be. I think the best solution (one that might actually work) would be to simply not allow editing while debugging!
Wouldn't it be easier to just clear the breakpoints from the point of edit to the end of the file? I can deal with tracing around a file that doesn't quite match the current source. But I can't deal with setting and clearing phantom breakpoints.
I don't think so. You would not only need to clear the existing breakpoints, you would also need to disallow adding of any breakpoints below the "point of edit". And for what purpose? Why should editing have higher priority than debugging, while in _debugging_ mode? I still think editing should be disallowed while debugging. It makes sense, and could probably even be made to work.
*** Bug 149301 has been marked as a duplicate of this bug. ***
The appearence of additional breakpoints when editing while running is fixed. Making the editor read-only we won't do.