bugGNU Octave - Bugs: bug #46632, Breakpoints and program counter...

 
 

bug #46632: Breakpoints and program counter arrow aren't cleared in some cases

Submitter:  None
Submitted:  Tue 08 Dec 2015 02:11:10 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  lachlan
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 08 Nov 2016 07:16:55 PM UTC, comment #19: 

I just submitted a patch for bug #49171.  It's not great, but it seems to solve the problem reported there without breaking the examples in comment #9.

Rik <rik5>
Group administrator
Tue 08 Nov 2016 06:58:34 PM UTC, comment #18: 

Rik, I can confirm the behavior in he sense that when saving a file from the editor, Octave complains about parse errors that had just been fixed in the editor.

However, I think this error has popped up more recently than end of July; maybe only a month ago.
Has it been tried to back out the offending changeset in comment #14 to see if it helps?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 08 Nov 2016 05:11:06 PM UTC, comment #17: 

Added a dependency to bug #49171.  The fix for breakpoints and program counter arrows, is now causing the old file to be parsed rather than the current file in a "save" operation.

Rik <rik5>
Group administrator
Tue 26 Jul 2016 12:32:25 AM UTC, comment #16: 

Thanks.  Closing report.

John W. Eaton <jwe>
Group administrator
Tue 26 Jul 2016 12:14:46 AM UTC, comment #15: 

I tried the original instructions and now it seems to be working correctly.

I tried other thing also and there were no problems 

I think it can be closed.

          Doug

Doug Stewart <dastew>
Mon 25 Jul 2016 11:53:47 PM UTC, comment #14: 

I updated this changeset and pushed it here:

  http://hg.savannah.gnu.org/hgweb/octave/rev/acdd8983d308

Can someone verify that it is still working and if so, we can close this report.

Thanks.

John W. Eaton <jwe>
Group administrator
Tue 03 May 2016 01:05:36 PM UTC, comment #13: 

I can confirm the latest patch (comment #10) works OK in the cases in comments 1, 3 and 9.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 03 Mar 2016 09:51:05 AM UTC, comment #12: 

I mean "now", not "no" :)

Ruslan <l0110111>
Thu 03 Mar 2016 09:50:35 AM UTC, comment #11: 

No seems to work in all cases I checked.

Ruslan <l0110111>
Thu 03 Mar 2016 09:07:11 AM UTC, comment #10: 

Thanks, Ruslan.

The problem was due to a delay in the mechanism for executing commands from within GUI code.  I've put in a hack to wait for the "dbquit" command to complete.

I'm not sure if there is a better technique.  It isn't possible to call Fdbquit directly, since it throws an interrupt exception rather than returning.

(file #36533)

Lachlan Andrew <lachlan>
Wed 02 Mar 2016 10:20:44 AM UTC, comment #9: 

One case fixed, another not.
Fixed:
1. Make a breakpoint
2. Run
3. Stop
4. Change file, save
5. Run (now the breakpoint is preserved)

Still broken:
1. Make a breakpoint
2. Run
3. Change file, press Ctrl+S
4. Answer "Save" in the newly-appeared dialog
5. See breakpoints are lost

Ruslan <l0110111>
Wed 02 Mar 2016 07:02:26 AM UTC, comment #8: 

Oops!  I should have noticed that.  The attached patch should fix the problem.

The problem wasn't actually that my patch removed the breakpoints.  They are automatically removed when the file is saved, and restored afterwards.  The problem was that I was clearing the file from memory before it had recorded where the breakpoints were.  Now it does it after.

(file #36524)

Lachlan Andrew <lachlan>
Mon 29 Feb 2016 10:55:01 AM UTC, comment #7: 

After some testing, I've found a problem with your patch. Namely, after saving the file all breakpoints set in that file are lost. This behavior is quite painful for the user (see bug #47295 for some discussion). The least what should be done is restoration of breakpoints somewhere near the lines they used to be. Even better would be if Octave tracked added/removed lines to update breakpoints position (or delete a breakpoint if the containing line has been deleted).

Ruslan <l0110111>
Thu 25 Feb 2016 12:09:27 PM UTC, comment #6: 

After applying only the previous patch the yellow arrow behaves correctly.
After applying only the new patch I haven't found any anomalies with breakpoints. Basically the problematic cases now give a message asking whether to quit debugging mode, so no way to exactly reproduce, but anything I tried didn't lead to anomalies, so that's OK.
The new patch doesn't appear address the arrow problem, so both patches have to be applied to completely fix this bug.

Ruslan <l0110111>
Tue 23 Feb 2016 10:25:38 PM UTC, comment #5: 

Ruslan, the attached patch should fix the error.  It works on the example you gave.

Could you please have a try and let me know if any changes are needed?

(file #36446)

Lachlan Andrew <lachlan>
Sat 06 Feb 2016 01:41:04 AM UTC, comment #4: 

Ruslan, the yellow arrow issue is easy to resolve.  See the attached patch.

The issue of breakpoints is that Octave is using a cached version of the file, in which the blank line is still there.  Notice that when you can't place the breakpoint on test2=2, you can place one on the comment following  end.

I'm still thinking of where in the code to force the reload.

(file #36261)

Lachlan Andrew <lachlan>
Fri 15 Jan 2016 04:54:29 PM UTC, comment #3: 

Thanks, that commit is definitely an improvement, but still not complete: yellow arrow still remains there after quitting the debug mode.
Also the following sequence shows another case when breakpoint isn't cleared (should I file separate bug reports for these problems?):
With the same test file, do
1. Break at "test2=2;"
2. Run
3. Insert newline before breakpoint
4. Save
5. Press "Quit Debug Mode"
6. Remove the breakpoint
7. Remove the newline added in step 3
8. Save
9. Try to set breakpoint as in step 1
10. See breakpoint on "end" instead of "test2=2;"
11. Run
12. Try to clear breakpoint at "end"
13. See it still there
If you quit debug mode, you'll see the breakpoint actually vanish.

Ruslan <l0110111>
Fri 15 Jan 2016 12:06:09 PM UTC, comment #2: 

This should be fixed in changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/0a09c3cae800

Can the bug report be closed now?

Lachlan Andrew <lachlan>
Tue 08 Dec 2015 02:14:20 PM UTC, comment #1: 

Somehow the rest of text got eaten by the site. Here's another try:


% start file
function octave_test()
test=1;
test2=2;
end
% end file


Steps to reproduce:
1. Make a breakpoint at "test2=2;" line
2. Run
3. When breakpoint is hit, add a newline after "test=1;"
4. Press "Quit Debug Mode"

If you saved the file between steps 3 and 4, then you have red breakpoint icon and yellow program counter arrow, which you can't remove except by reopening the file.

If you didn't save the file, you can remove the breakpoint, but the yellow program counter arrow will still remain there or on the "end" line.

In any case, you can make a breakpoint on another line ("test=1;") and repeat the experiment, now adding line break before this line. This will give you two unremovable yellow arrows and one unremovable breakpoint icon.

Ruslan <l0110111>
Tue 08 Dec 2015 02:11:10 PM UTC, original submission:  

You can reproduce this on a simple file with the following code:


% start file
function octave_test()
test=1;
test2=2;
end
% end file
+verbatim+

Steps to reproduce:
1. Make a breakpoint at "test2=2;" line
2. Run
3. When breakpoint is hit, add a newline after "test=1;"
4. Press "Quit Debug Mode"

If you saved the file between steps 3 and 4, then you have red breakpoint icon and yellow program counter arrow, which you can't remove except by reopening the file.

If you didn't save the file, you can remove the breakpoint, but the yellow program counter arrow will still remain there or on the "end" line.

In any case, you can make a breakpoint on another line ("test=1;") and repeat the experiment, now adding line break before this line. This will give you two unremovable yellow arrows and one unremovable breakpoint icon.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #36446:  bug_46632_cursor_v2.cset added by lachlan (5KiB - application/octet-stream)
file #36261:  bug_46632_cursor.cset added by lachlan (878B - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by l0110111 (Posted a comment)
  •  

    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 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-08 rik5 Dependencies- bugs #49171 is dependent
    2016-07-26 jwe StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2016-07-25 jwe StatusPatch Submitted Ready For Test
    2016-04-17 philipnienhuis Carbon-Copy- Added philipnienhuis
    2016-03-03 lachlan Attached File- Added bug_46632_cursor_and_breakpoints_v2.cset, #36533
    2016-03-02 lachlan Attached File- Added bug_46632_cursor_and_breakpoints.cset, #36524
    2016-02-23 lachlan Attached File- Added bug_46632_cursor_v2.cset, #36446
        Item GroupNone Other
        StatusNone Patch Submitted
        Assigned toNone lachlan
        Release4.0.0 dev
    2016-02-06 lachlan Attached File- Added bug_46632_cursor.cset, #36261

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code