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

 
 

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

Submitter:  Ruslan <l0110111>
Submitted:  Sun 28 Feb 2016 03:10:09 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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?

Anonymous
Sun 28 Feb 2016 03:10:09 PM UTC, original submission:  

Test with the following code:


function octave_test1()
x=5;
y=6
z=7;
end


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:
   
   
Comment:
   

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
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-29 rik5 StatusWont Fix Invalid / Not an Octave Bug
        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.13-f8d8.
    Corresponding source code