bugGNU Octave - Bugs: bug #56150, Regressions with debugger

 
 

bug #56150: Regressions with debugger

Submitter:  Rik <rik5>
Submitted:  Wed 17 Apr 2019 03:54:36 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  jwe
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 11 Jul 2019 09:05:40 PM UTC, comment #10: 

I created a new bug report for the dbquit feature: bug #56616

John W. Eaton <jwe>
Group administrator
Thu 11 Jul 2019 08:42:07 PM UTC, comment #9: 

This works for me again.  Closing report.

I don't see that we implement "dbquit all".  If you have any additional options to dbquit it complains and calls print_usage().  I do see that Matlab has this syntax, but maybe make a new feature request issue report if you are considering adding the functionality.

Rik <rik5>
Group administrator
Thu 11 Jul 2019 07:21:54 PM UTC, comment #8: 

I pushed the following change:

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

It seems to work for me now.

I'm also looking at "dbquit" vs. "dbquit all".

Do you see any other problems?


John W. Eaton <jwe>
Group administrator
Wed 10 Jul 2019 11:01:30 PM UTC, comment #7: 

OK, I'll take another look at it.

John W. Eaton <jwe>
Group administrator
Wed 10 Jul 2019 08:53:38 PM UTC, comment #6: 

Uh oh, something seems to have gone wrong with the debugger after the patch was committed.  Here is a sample Octave session showing the problem.


octave:1> dbstop unique
ans =  55
octave:2> [c,a,b] = unique ([1 3 6 1])
stopped in unique at line 55 [/home/rik/wip/Projects_Mine/octave-dev/scripts/set/unique.m]
55:   if (nargin < 1)
debug> dbnext
error: internal error: dbstep without an active debugger!
error: called from
    unique at line 57 column 3


Re-opening the bug report and marking as "In progress".

Rik <rik5>
Group administrator
Mon 08 Jul 2019 03:30:39 PM UTC, comment #5: 

Back from vacation.  Tested and problem is solved.  Closing report.

Rik <rik5>
Group administrator
Thu 04 Jul 2019 02:33:19 PM UTC, comment #4: 

I pushed the following changeset:

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

Your examples seem to work for me now.  If you agree, please close.  Otherwise, let me know what else is broken and I'll try to fix.

John W. Eaton <jwe>
Group administrator
Wed 12 Jun 2019 08:54:40 PM UTC, comment #3: 

Whoops, I realize I uploaded the wrong script for testing.  The new script is db_prompt.m shown below.


## This is a script for testing the debugger's prompt
x = 1;

keyboard;

y = 2;


When you execute it repeatedly the debugger nesting level continually increases.  Apparently the code to restore the debug level at the end of a debugging session is not working.

Sample session:


octave:2> db_prompt
stopped in db_prompt at line 4 [/home/rik/wip/Projects_Mine/octave-dev/db_prompt.m]
4: keyboard;
keyboard> dbcont
octave:3> db_prompt
stopped in db_prompt at line 4 [/home/rik/wip/Projects_Mine/octave-dev/db_prompt.m]
4: keyboard;
[1]keyboard> dbcont
octave:4> db_prompt
stopped in db_prompt at line 4 [/home/rik/wip/Projects_Mine/octave-dev/db_prompt.m]
4: keyboard;
[2]keyboard> dbcont



Rik <rik5>
Group administrator
Wed 17 Apr 2019 04:38:54 PM UTC, comment #2: 

The recursion level is not being reset when exiting the debugger.

I used


debug_on_error (1)
db_prompt
dbquit
db_prompt


Each set of "db_prompt; dbquit" causes the printed recursion level to increase.


Rik <rik5>
Group administrator
Wed 17 Apr 2019 04:10:55 PM UTC, comment #1: 

The debugger may now be entered recursively so the "[N]" part is there to give you some clue about the recursion level.  We could make it optional.  It is supposed to be reset as you pop out of the recursive call.  Is that not happening?  Does it work properly if you only enter one command per line at the debug prompt?

John W. Eaton <jwe>
Group administrator
Wed 17 Apr 2019 03:54:36 PM UTC, original submission:  

Use the attached script (db_prompt.m) and then execute


debug_on_error (1)
db_prompt


Issue #1: The resulting debugger prompt is "[1]debug>".  I checked PS1() and the interpreter has temporarily set PS1 to this odd value.  If you use "dbquit; db_prompt" then you can get the initial count to increment to "[2]", "[3]", etc.

Issue #2: I can move up/down the stack with dbup/dbdown but the code listing (dblist) is always stuck at the lowest level of the stack.  It seems that dbwhere is correctly updated when the stack level changes.

Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #46786:  db_script.m added by rik5 (291B - text/x-matlab)

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2019-07-11 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2019-07-11 jwe StatusFixed In Progress
        Open/ClosedClosed Open
    2019-07-11 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2019-07-10 rik5 StatusFixed In Progress
        Open/ClosedClosed Open
    2019-07-08 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-07-04 jwe StatusConfirmed Ready For Test
    2019-06-12 rik5 StatusNone Confirmed
    2019-04-17 rik5 Attached File- Added db_script.m, #46786

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code