I have set breakpoint on begin, in the middle and on end of some C/C++ file. Being in the middle of code I remove/add couple lines of code. Now I check breakpoints view and I can see that breakpoint(s) placed after removed/added code still points to the same row number. I click into it and as I expect I'm moving to wrong line. Whereas breakpoint icon placed on left bar is set next to correct row. In this moment changing breakpoint(s) by clicking in correct place sometimes might provide to CRASH. Reproducible: Always Steps to Reproduce: 1. Open C/C++ file 2. Set couple of breakpoints 3. Delete couple of lines of code placed before any breakpoint(s) Actual Results: All breakpoints placed after removed code now indicate invalid lines. Expected Results: Number of row for all breakpoints placed after removed code should be properly updated (in Breakpoints view). KDevelop and KDevplatform cloned at 14.05.2016 from brach 5.0 Bug is related with #353101, but it refers to old KDevelop line (in this case 4.7.1)
I'm seeing exactly same behaviour. I also had kdevelop crashing instantly on me by adding lines above the break points and then trying to remove/change/add the breakpoints then. Bigger the project was the sooner kdevelop may crash. Usually no crash happens except that break points go invalid and I manage to 'fix' the break points by removing them and adding them back. I think this bug is rather severe as I have lost data because of it. I have Kdevelop 5.0.3, KDE Frameworks 5.30.0, Qt 5.7.1. Please fix this issue on next release. I don't like instantly segfaulting sofware.
Hmm, can't reproduce the crash but yes, the display is definitely buggy, we need to look into that. But, how did you lose data? Crash recovery should easily be able to restore all changes to the file in this case ...
Fixed in Bug 424431
(In reply to Piotr Mierzwinski from comment #3) > Fixed in Bug 424431 Are you sure this bug is really fixed already? Even with the fix for Bug 424431, Breakpoints view only synchronizes when the document is saved. See https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147#note_89877
(In reply to Igor Kushnir from comment #4) > (In reply to Piotr Mierzwinski from comment #3) > > Fixed in Bug 424431 > Are you sure this bug is really fixed already? Even with the fix for Bug > 424431, Breakpoints view only synchronizes when the document is saved. See > https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147#note_89877 This issue is definitely not resolved. Reopening it.
(In reply to Sven Brauch from comment #2) > Hmm, can't reproduce the crash but yes, the display is definitely buggy, we > need to look into that. > > But, how did you lose data? Crash recovery should easily be able to restore > all changes to the file in this case ... This is such an old issue, I don't remember anymore. :-/ Recent kdevelop versions: 5.11.230403 (23.04.3) have not crashed anymore for long time by fiddling with the break points. (In reply to Axel Kellermann from comment #5) > (In reply to Igor Kushnir from comment #4) > > (In reply to Piotr Mierzwinski from comment #3) > > > Fixed in Bug 424431 > > Are you sure this bug is really fixed already? Even with the fix for Bug > > 424431, Breakpoints view only synchronizes when the document is saved. See > > https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147#note_89877 > This issue is definitely not resolved. Reopening it. I was supprised this issue is *still* open and that I had an comment here. :-) I have bug-fix/feature request how to solve this: The Core problem persist as of 5.11.230403 (23.04.3): break points are not kept up to date with editing the source. All break points are updated in document when user adds/toggles/removes them. Current behavior of kdevelop is to keep the break point on the exact line number it was set on, even if that source line doesn't exists anymore since the break points were last updated. This very annoying when you add/remove source lines from source file before any enabled break points. But it is better than nothing. My suggestion how to solve this: When break point is set kdevelop should to record the source line *hash* it was set on. When that source line moves, kdevelop can attempt to update the break point line number based on this break point context (the source line hash) If the break point context doesn't match anything in the file it was enabled in kdevelop should *disable* it, as the code user enabled it on is unlikely to exists anymore. When recording new break point context it might be good idea to ignore white-space parts of the source line: This would allow slightly editing the source line and the hash would still match the source line. As last note adding an "Refresh break points" command to the IDE would be nice.
See my comment in the MR mentioned above: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147#note_89877 BreakpointModel already contains all the logic needed to resolve the issue. What's missing is an appropriate event to react on. And as remarked by Igor, it would probably also be a good idea to refactor the code in BreakpointModel a bit to prevent a potential negative impact on performance. Maybe one of the more senior KDE/KDevelop devs could have a look at my comment in the MR and assess if my statement makes sense and how it could be implemented.
Created attachment 161751 [details] patch 1/2 Wire an new event handler in BreakpointModel.
Created attachment 161752 [details] patch 2/2 The RFC bug fix.
I scratched my itch with this bug. I want it *gone*. :-) I built the kdevelop in the LXC container last week: I used the kdesrc-build tool to build and checkout the sources. I checkout master branch at 4c984656ade6e602dbd8ac4c7e4bbf440aad7173 commit. My first question is: is this the correct branch for bug fix development? The initial thing I did was run kdevelop under GDB: This allowed me to dissect what was happening. After browsing and running the code enough, I found a suitable event for updating the BreakpointModel on the Kdevelop side: void MarkInterface::marksChanged(KTextEditor::Document *document); This is the *only* signal activated when the editor updates the mark(s) in the document. This is implemented in ktexteditor/src/document/katedocument.h by the KTextEditor::DocumentPrivate. I have now noticed that this API looks to be internal to ktexteditor? It's unfortunate if this can't be used because I actually managed to write a crude bug-fix patch using it. The linked patches are *not* the real fix. I provided them here only so that I could get in contact with the developers. And yes, the BreakpointModel code looks... bit iffy even to me.
(In reply to JATothrim from comment #10) > I scratched my itch with this bug. I want it *gone*. :-) Welcome to KDevelop development :) > I checkout master branch at 4c984656ade6e602dbd8ac4c7e4bbf440aad7173 commit. > My first question is: is this the correct branch for bug fix development? Yes, unless the bug fix is simple and safe enough to be included in the stable branch, which the fix to this bug is unlikely to end up. > void MarkInterface::marksChanged(KTextEditor::Document *document); > > This is the *only* signal activated when the editor updates the mark(s) in > the document. > > This is implemented in ktexteditor/src/document/katedocument.h by the > KTextEditor::DocumentPrivate. > > I have now noticed that this API looks to be internal to ktexteditor? > It's unfortunate if this can't be used because I actually managed to > write a crude bug-fix patch using it. MarkInterface is part of public KTextEditor API: https://api.kde.org/frameworks/ktexteditor/html/classKTextEditor_1_1MarkInterface.html > The linked patches are *not* the real fix. > I provided them here only so that I could get in contact with the developers. You can create a Draft merge request at https://invent.kde.org/kdevelop/kdevelop.