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

 
 

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

Submitted by:  Rik <rik5>
Submitted on:  Thu 28 Apr 2016 04:26:20 AM UTC  
 
Category: GUISeverity: 2 - Minor
Priority: 3 - LowItem Group: Incorrect Result
Status: Wont FixAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project Member
Thu 28 Apr 2016 04:26:20 AM UTC, original submission:

Steps to reproduce.

Create a file tmp.m with the following contents

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.

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>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by rik5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 28 Apr 2016 07:14:15 PM UTCrik5StatusNone=>Wont Fix
      Open/ClosedOpen=>Closed
    Thu 28 Apr 2016 04:26:36 AM UTCrik5Severity3 - Normal=>2 - Minor
      Priority5 - Normal=>3 - Low

    Back to the top


    Powered by Savane 3.1-cleanup1