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

Submitter:  Marshall <marsian>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 19 Feb 2020 11:05:30 PM UTC, comment #13: 

I still see this in 5.2.0. I'm not sure about dev versions. It's been a while since I've compiled Octave myself.

Marshall <marsian>
Sat 15 Feb 2020 10:19:41 PM UTC, comment #12: 

Is this bug still present? I can not confirm the issue on a recent build from the dev branch by following the steps given in comment #7

Torsten Lilge <ttl>
Group Member
Sat 07 Sep 2019 02:09:03 PM UTC, comment #11: 

I've been looking at GUI<->interpreter threading issues and came across this bug report.

A newline at the command prompt "fixes" the problem because it updates the value of the Vlast_prompt_time variable and that is used to determine whether to check for out of date functions.  Skipping that check between prompts is done for efficiency.

I think we need a way to bypass that check when updating breakpoints for a specific file.  I was initially tempted to simply to update the last prompt timestamp when saving a file, but then saving a file in the editor while the interpreter is busy would cause any functions to be checked and possibly parsed again, which could result in different behavior from what would happen if you saved a file with an external editor.

John W. Eaton <jwe>
Group administrator
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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group Member
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>
Group Member
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 jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by marsian (Submitted the item)
  •  

    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 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.13-f8d8.
    Corresponding source code