Mon 29 Feb 2016 04:22:35 PM UTC, comment #10:
Dev version works as expected. Closing report.
The discussion for the problematic patch can continue on bug #46632.
|
Mon 29 Feb 2016 10:48:47 AM UTC, comment #9:
OK, sorry, I was wrong about the development version, that behavior was because I had patches for bug #46632 applied, which cleared the breakpoints.
|
Mon 29 Feb 2016 06:19:02 AM UTC, comment #8:
When I tested it several days ago, the development version removed all breakpoints after I pressed Ctrl+S while debugging when I clicked "Save" in "Quit debugging mode?" dialog. Has it changed since then?
|
Mon 29 Feb 2016 06:10:35 AM UTC, comment #7:
In the current development version, the breakpoints are restored after saving the file.
|
Mon 29 Feb 2016 04:47:30 AM UTC, comment #6:
Well, I'd agree if it only removed the breakpoints when the file was changed externally. But if the file was edited in Octave's own editor, Octave can have tracked where the lines were added or removed and move/delete the breakpoints correspondingly in the process of editing instead of deleting them all. I seem to remember from past experience with Matlab that it did exactly this. It never removed all the breakpoints just because I saved the file.
This issue report was actually the result of such painful difference of Octave behavior from Matlab's.
|
Mon 29 Feb 2016 01:03:43 AM UTC, comment #5:
The existing behavior is explicitly intended. When the timestamp on a file changes, indicating it has been edited, Octave has no way of knowing the extent of the changes. Because Octave records breakpoints only by file and line number, rather than a contextual diff which would include nearby lines, it throws away the existing breakpoints as invalid. Matlab behaves similarly, I believe.
I've changed the category to feature request and changed the summary to what might be possible.
|
Sun 28 Feb 2016 08:53:01 PM UTC, comment #4:
And, just a suggestion, you might consider a script
which reapplies the breakpoints that you want.
|
Sun 28 Feb 2016 08:49:38 PM UTC, comment #3:
It appears that you want something like
dbsuspend/dpresume. But, this is not likely
easy to implement. After you have edited the file
reestablishing the breakpoints not be easy, or in
some cases even possible.
In any case, this should be moved to the new feature
request page.
I do agree that this feature would be nice to have.
I have not checked, but I do not remember that Matlab
provides this capability.
|
Sun 28 Feb 2016 03:42:20 PM UTC, comment #2:
No, dbcont is opposite of what I need in this case. I need to edit the file and restart debugging from the beginning with the same breakpoints. The example code here is of course trivial, but actual files can be larger, and can have tens of breakpoints. Losing all them on debuggee restart is a painful experience.
|
Sun 28 Feb 2016 03:26:28 PM UTC, comment #1:
This doesn't seem like a bug -- when you exit debug mode (dbquit), normal operation is carried out on the next execution. If you want debug mode to be retained, you may want to try dbcont instead of dbquit. Is that OK?
|
Sun 28 Feb 2016 03:10:09 PM UTC, original submission:
Test with the following code:
Steps to reproduce:
1. Set breakpoints on three lines of assignment to x,y,z
2. Run (F5)
3. On hitting the first breakpoint, Stop ("Quit Debug Mode")
4. Add a new line after `z=7;`
5. Save
6. Run
After step 6 you'll see that breakpoints have vanished, and terminal has `y = 6` output, meaning that the program has actually executed past all the original breakpoints.
|