bugGNU Octave - Bugs: bug #47796, GUI allows breakpoints to be set...

 
 

bug #47796: GUI allows breakpoints to be set on empty line at EOF

Submitter:  Rik <rik5>
Submitted:  Thu 28 Apr 2016 04:26:20 AM UTC
   
 
Category:  GUI Severity:  2 - Minor
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 28 Apr 2016 07:14:15 PM UTC, comment #3: 

Yes, I did consider the utility of being able to stop just before the exit of a function.  I just didn't know whether that was an intended, or unintended, effect.  Since it was intentional I'm going to close this report.

Rik <rik5>
Group administrator
Thu 28 Apr 2016 06:20:32 PM UTC, comment #2: 

It's a feature that you can set a breakpoint at or step to the end of a function or script after all executable statements have been evaluated.  That way you can examine all variables that have been set.  I guess you can think of it as setting a breakpoint just before the implicit "return" statement is evaluated.  I think Matlab also behaves this way.

I see 6 returned from dbstop instead of 7 and if I try dbstop FILE 6, it returns 0.  But maybe you have one more blank line in the file than I do?

John W. Eaton <jwe>
Group administrator
Thu 28 Apr 2016 09:49:38 AM UTC, comment #1: 

Is that a bug or a feature?

A breakpoint stops before the command is executed.  This breakpoint on the blank line causes a breakpoint to occur after the last command of the script is executed, but before returning to the caller.  That would be impossible if breakpoints could only be placed on non-empty lines.

Regarding dbstatus, note that the file and octave are resynchronised when the file is saved.  Matlab turns the breakpoint symbol grey when the file has been edited.  We already have a visual indication that the file has been edited (the star in the tab), and so the alert user can know that the position of the breakpoint can't be trusted.

Lachlan Andrew <lachlan>
Thu 28 Apr 2016 04:26:20 AM UTC, original submission:  

Steps to reproduce.

Create a file tmp.m with the following contents


a = 1;
b = 2;
c = 3;
d = 4;



Open tmp.m in the editor.  Double-click to set a breakpoint at line 5 (empty, but not last line in file).  The breakpoint is set at the last line in the file (line 6).

To be fair, this might just be dbstop's fault.  When you call it with a line number it searches for the next breakable line, which might not be the correct one.


dbstop tmp 5
ans =  7


More fun can be had by entering the editor and using the backspace to delete empty lines.  The red breakpoint bubble follows the deleted line so it shows that there is a breakpoint at line 4.  However, if you go back to the command window and execute dbstatus, the breakpoint is still reported on line 7.

Rik <rik5>
Group administrator

 

(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 lachlan (Posted a comment)
  • -email is unavailable- added by rik5 (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-28 rik5 StatusNone Wont Fix
        Open/ClosedOpen Closed
    2016-04-28 rik5 Severity3 - Normal 2 - Minor
        Priority5 - Normal 3 - Low

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code