Breakpoints not updating with file changes
DevAgu93 opened this issue · 5 comments
In the video I set a breakpoint and the program stops, but when I add a bunch of new lines to the file, the breakpoint stays in place and the debugger acts as if the file was not updated, meaning that other breakpoints won't get detected at the correct place. This gets fixed by closing and re opening Raddbg.
raddbg_NKq3HY42yW.mp4
This is expected behavior. You have modified the source code without rebuilding your program, which invalidates line info within the debug info. The debugger can't really do much about making this correct. The breakpoints you place after editing the file are presumably inside of a branch that isn't taken, so they never get hit. It just doesn't look like this because you've modified the file, thus making the debug info (and the executable) stale, as compared to the source code.
That being said, this reminds me that my warning UI for exactly this case is missing after my recent pass over the source view, so I will fix that.
You're right, that was a mistake from my part. I apologize.
There is still another problem though. I tried to do the same but this time I compiled the program after modifying the file. The video shows how the breakpoint gets set on the wrong place after reverting the file changes:
raddbg_nBLj97oP8A.mp4
Nothing I see in the video is outside of intended behavior still; in RADDBG, breakpoints placed on lines without line info (e.g. a comment or blank line) will apply to the next subsequent line with line info (visualized by the red line). There is currently no path for breakpoints to adjust their position in the presence of file changes (e.g. by heuristic rules using diffs), so breakpoints will just stay on whatever line they were set at. You set a breakpoint on line 34, changed the file, rebuilt, but the latter two steps don't matter to the breakpoint placement right now, so the breakpoint stayed on line 34.
I see, I expected the breakpoint to adjust itself to the original instruction as I'm used to with Visual studio.
Yeah, Visual Studio uses some kind of heuristic diff rules to adjust breakpoint positions as the underlying file is edited. It's not an ideal solution but it works for simple cases. At some point we will likely do something like that, but it's not in there yet. I've re-added that warning for out-of-date debug info as of d78afc5, so the UI should help warn you of this. Closing this now.