bugGNU Octave - Bugs: bug #47295, Keep existing breakpoints after...


bug #47295: Keep existing breakpoints after editing file in GUI

Submitted by:  Ruslan <l0110111>
Submitted on:  Sun 28 Feb 2016 03:10:09 PM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Invalid Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  4.0.0 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

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.

Rik <rik5>
Project Administrator
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.

Ruslan <l0110111>
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?

Ruslan <l0110111>
Mon 29 Feb 2016 06:10:35 AM UTC, comment #7: 

In the current development version, the breakpoints are restored after saving the file.

Torsten Lilge <ttl>
Project Member
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.

Ruslan <l0110111>
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.

Rik <rik5>
Project Administrator
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.

Michael Godfrey <godfrey>
Project Member
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.

Michael Godfrey <godfrey>
Project Member
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.

Ruslan <l0110111>
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:

function octave_test1()

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.

Ruslan <l0110111>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by l0110111 (Submitted the item)
  • -email is unavailable- added by l0110111

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-29 rik5 StatusWont Fix => Invalid
        Open/ClosedOpen => Closed
    2016-02-29 rik5 Item GroupOther => Feature Request
        StatusNone => Wont Fix
        SummaryBreakpoints are lost after saving file => Keep existing breakpoints after editing file in GUI
    2016-02-28 l0110111 Carbon-Copy- => Added -email is unavailable-

    Back to the top

    Powered by Savane 3.7