bugGNU Octave - Bugs: bug #53702, GUI editor break points use...

 
 

bug #53702: GUI editor break points use out-of-date line numbers when a file is modified

Submitted by:  Marshall <marsian>
Submitted on:  Thu 19 Apr 2018 06:01:43 PM UTC  
 
Category:  GUI Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Marsian Open/Closed:  Open
Release:  dev Operating System:  Any

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)

Fri 08 Mar 2019 06:25:37 PM UTC, comment #10: 

The effect described in comment #7 can also be observed when using dbstop / dbstatus in the cli version of octave. Therefore it is not necessarily a bad synchronization by the gui editor that leads to the issue.

When, after modifying and saving the file, breakpoints in the editor are shown at lines that are in general not allowed for breakpoints, then these lines are also listed by dbstatus. Thus, the gui is in line with the bp infos of octave. Doesn't this imply that dbstop does not respect the new file contents?

Torsten Lilge <ttl>
Project Member
Fri 08 Mar 2019 12:11:20 AM UTC, comment #9: 

And to confirm comment #2 still, closing and reopening the file alone does not resolve this. At least one command or one empty newline has to be entered at the Octave prompt, only then all stale breakpoints in the affected file are cleared.

Mike Miller <mtmiller>
Project Administrator
Mon 04 Mar 2019 09:31:32 AM UTC, comment #8: 

Just to confirm:
I very rarely hit this issue of stale breakpoint locations and finding it impossible to set breakpoints on lines of code otherwise looking valid to me. I usually fix it by saving & reloading the file being debugged.
I have the impression that esp. code lines immediately following comment lines are affected, but I can't put a finger on it.

OTOH the situation is much better than it used to be > a year ago.
(I'm currently using 6.0.0 and occasionally 5.1.1)

Philip Nienhuis <philipnienhuis>
Project Member
Sun 03 Mar 2019 09:08:21 PM UTC, comment #7: 

Yes, I can still reproduce this with Octave 5 or on the development branch.

1. Place breakpoints in the editor.
2. Insert or delete lines in the editor and save the file. Breakpoints may be moved automatically to the wrong lines.
3. Place more breakpoints in the editor. Where they are allowed to be placed is based on the original file.
4. Run any command in the command window.
5. Place another breakpoint in the editor, previous breakpoints all disappear.

Or equivalently,

4. Run dbstatus in the command window, the breakpoints that were set (including the new invalid ones) are listed.
5. Run dbstatus again, breakpoints have now been cleared from the file that was modified and saved.

Mike Miller <mtmiller>
Project Administrator
Sun 03 Mar 2019 05:04:43 AM UTC, comment #6: 

The last comment on this bug report was from April, 2018.  Please try to reproduce this issue with the latest stable release which is 5.1.0.  The problem is likely to have been fixed.

Rik <rik5>
Project Administrator
Fri 27 Apr 2018 06:07:34 PM UTC, comment #5: 

I agree this is a valid bug. Reassigning to dev release.

Mike Miller <mtmiller>
Project Administrator
Tue 24 Apr 2018 10:51:38 PM UTC, comment #4: 

You gave some good tips on how to "fix it" without closing octave. Typing in the command line really helped. I was able to get debug points working on correct lines without even closing the editor file. Even though some breakpoints are lost, at least I can now place breakpoints where I want them. It still would be nice to have this fixed for real at some point.

Marshall <marsian>
Fri 20 Apr 2018 05:56:45 PM UTC, comment #3: 

Ok, I do see what you are getting at, but all of these examples do work for me if the file is closed in the editor, at least one command is entered in the command window, or even just a blank line with Enter, and then the file is reopened in the editor.

The GUI already tries to resynchronize the breakpoint state with the interpreter, but apparently this requires at least one command or an Enter to be done in the command window first.

I don't think this is a regression, and an easy workaround is available.

Mike Miller <mtmiller>
Project Administrator
Fri 20 Apr 2018 02:40:04 PM UTC, comment #2: 

For me, closing and reopening the file wasn't enough to correct the behavior, but closing and re-opening octave did fix it.

x = [1,2,3,40];%comments, Line 1

%comments;
for a=1:2
    for b = 1:2
        c = a + b;
        for d = 1:4
            % comments
            code = c^d;
            for e = 1:4
                for f = 1:2
                    g = sin{f};%Line 12
                    h = {a,b,c,d,f};

                    i = find(randi(2,5,1)-1,1,'first');
                    if i>3
                        %stuff
                        j = h{1};
                    endif
                    disp(code);%Line 20
                endfor
            endfor
        endfor
    endfor
endfor


disp(h);
%line 29

In the example code above I can initially place break points on any of the expected lines: Not the blank ones, comment lines or end statements. After placing all break points, copy lines 12 and 13 and paste just before line 20 (to be a new line 20 and 21). Save changes to the file. Breakpoints disappear from the new line 22 and show up on line 28 (a blank line). A new breakpoint can be placed on the new line 20, but not on 21 or 22. Close and re-open the file and where breakpoints can be placed doesn't change.

Now close and reopen octave. Place all break points. delete the new lines 20 and 21 just placed. Save. The breakpoint on 28 (disp(h)) disappears and can't be placed. There is a breakpoint on 21 (where it shouldn't be), and a new one can be placed on 22 (an endfor where it shouldn't). Close and reopen the file. Breakpoints can be placed the same as before: every they should except line 28, and can be placed where they shouldn't on 21 and 22.

x = [1,2,3,40];%comments, Line 1

%comments;
for a=1:2
    b = 1;
    for d = 1:4
        % comments
        code = b^d;
    endfor
    code2 = b^d;
endfor

disp(b);
%line 14

Place all breakpoints (including the blank line 15). Duplicate line 8. Save. Can't have breakpoint on 9 or 11, but yes on 10 (an endfor) and 13 (a blank line). Save, restart, add all breakpoints and delete the duplicate 8, save: no breakpoint allowed on 10 or 13 or 15 (a blank line), but yes on 11, (an endfor) and 14 (comment).

Marshall <marsian>
Thu 19 Apr 2018 07:03:14 PM UTC, comment #1: 

I would find it very helpful if you had some concrete examples to show what you mean.

It is true that Octave does not allow you to place debug points anywhere in a file, for example comments or blank lines can not be debug points. Lines that are only 'else' or 'endif' or 'endfor' can not be debug points in my experience.

But I do see that placing debug points with the GUI editor sometimes gets confused when a file is modified, saved, and then an attempt is made to insert a break point. If the file is closed and reopened, then it seems to work correctly for me.

Does that describe the behavior you are seeing? Does closing the file and reopening it in the editor always restore the correct behavior for you?

Mike Miller <mtmiller>
Project Administrator
Thu 19 Apr 2018 06:01:43 PM UTC, original submission:  

In the editor, I found that I can't place debug points on some lines of code as expected. I also found (in trying to pin point what makes it do this) that with a large number of debug points and deleting a section, that some debug points were placed on strange lines, e.g. an endfor line that didn't have it before. Sometimes it failed to place debug points on codes of line following some end statements but still within loops, and sometimes wouldn't place debug points on lines at the end of a file after some embedded for loops.
I am using octave 4.3.90 from http:/alpha.gnu.org/gnu/octave/octave-4.3.90-w64-installer.exe.

Marshall <marsian>

 

(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 marsian (Submitted the item)
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-08 rik5 Carbon-CopyRemoved 72865 => -
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 => -
    2018-04-27 mtmiller Release4.3.90 => dev
        Operating SystemMicrosoft Windows => Any
    2018-04-20 mtmiller Severity3 - Normal => 2 - Minor
        Item GroupRegression => Incorrect Result
        StatusNeed Info => Confirmed
        SummaryDebug points can't be set on some lines => GUI editor break points use out-of-date line numbers when a file is modified
    2018-04-19 mtmiller StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5