bugGNU Octave - Bugs: bug #56625, debug prompt can change erratically

 
 

bug #56625: debug prompt can change erratically

Submitter:  Rik <rik5>
Submitted:  Fri 12 Jul 2019 10:56:56 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  3 - Low Item Group:  Regression
Status:  Fixed Assigned to:  None
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

Wed 24 Jul 2019 08:03:41 PM UTC, comment #10: 

Thanks much for the changesets.  I'm going to close this report as the original issue has been well taken care of.

One other thought, and maybe it should get put on the Octave Maintainer's list as a question, is the numbering for the debug level.

When you walk in to a building, what is the number of that floor and the floor above it?  In the U.S., the answer is 1st floor and 2nd floor.  In Europe, it is ground floor and 1st floor.

I notice that the first level in the debugger is European in that it is implicitly numbered 0.  Being American, I kind of expect 1.  Here's a session demonstrating that.


octave:1> dbstop ls
ans =  58
octave:2> ls
stopped in ls at line 58 [/home/rik/wip/Projects_Mine/octave-dev/scripts/miscellaneous/ls.m]
58:   if (! iscellstr (varargin))
debug> ls
stopped in ls at line 58 [/home/rik/wip/Projects_Mine/octave-dev/scripts/miscellaneous/ls.m]
58:   if (! iscellstr (varargin))
[1]debug> ls
stopped in ls at line 58 [/home/rik/wip/Projects_Mine/octave-dev/scripts/miscellaneous/ls.m]
58:   if (! iscellstr (varargin))
[2]debug> dbstack
stopped in:

  --> ls at line 58 [/home/rik/wip/Projects_Mine/octave-dev/scripts/miscellaneous/ls.m]
      ls at line 58 [/home/rik/wip/Projects_Mine/octave-dev/scripts/miscellaneous/ls.m]
      ls at line 58 [/home/rik/wip/Projects_Mine/octave-dev/scripts/miscellaneous/ls.m]


The last call to dbstack shows that I am three levels deep but the prompt shows just 2.  Either convention is fine, but maybe one is less confusing?

Rik <rik5>
Group administrator
Wed 24 Jul 2019 04:43:12 PM UTC, comment #9: 

I pushed two more changes that further improve the behavior for me when using dbnext and stepping back out to the top-level REPL:

http://hg.savannah.gnu.org/hgweb/octave/rev/9dcbc0a449af
http://hg.savannah.gnu.org/hgweb/octave/rev/9b053ba971b2

John W. Eaton <jwe>
Group administrator
Wed 24 Jul 2019 03:57:24 AM UTC, comment #8: 

I think your last changeset clarifies things enough that I could close the report.

Separately, I see a strange issue with dbnext walking off the end of the function.

If I run "tst_dbp2" and then use dbnext until I return to the Octave prompt, then try a command like "sin (5)" it throws me back to a debug prompt.  The command dbstack returns nothing showing that I'm not in a true debugging context.  It is only if I do something that finishes a debugging session, such as dbquit or dbcont, that I can truly get back to the regular prompt.

Rik <rik5>
Group administrator
Tue 23 Jul 2019 07:38:26 PM UTC, comment #7: 

I pushed the following additional change.  I think it helps to avoid some (maybe most) of the confusion by preventing errors that occur at aany debug or keyboard prompt from pushing us to a new debug level.

http://hg.savannah.gnu.org/hgweb/octave/rev/52542cfcc7dc

Also, the reason for the change from "keyboard> " to "debug> " when you execute "dbnext" at the "keyboard> " prompt is that you are moving away from the point of the keyboard command line and stepping to the next statement in the code.  You can think of that as moving to a temporary breakpoint.  Since it is not a keyboard statement, it doesn't use the "keyboard> " prompt.

John W. Eaton <jwe>
Group administrator
Tue 23 Jul 2019 06:57:20 PM UTC, comment #6: 

Yes, it is confusing, so I think it is worth fixing so it behaves more consistently.

I see now that the way the keyboard function enters the debugger is different from what happens when it is entered on an error when debug_on_error is TRUE.  When we enter the debugger because of an error, the debug_on_error state is reset to FALSE.  When we enter with keyboard, it is not.  I think maybe the correct thing to do is to set it to false any time we are at a debug or keyboard prompt so that mistakes on those command lines don't push us into new deeper debugging levels.  Maybe that fix alone would remove most of the confusion?

I'll also take a look at the debug vs. keyboard prompt thing.  Maybe it would be best just to use "debug> " (with a debugging level indicator) always instead of trying to use "keyboard> "?  Or, just use "K>> " always if running in --traditional mode?

John W. Eaton <jwe>
Group administrator
Tue 23 Jul 2019 06:41:34 PM UTC, comment #5: 

I like the idea of indicating how many levels deep one is in the debug hierarchy.  In normal debug circumstances I understood how I got from "debug>" to "[1]debug>" to "[2]debug>".

It is just confusing, to me, that I'm in a "keyboard>" instance of debugging, then by typing 'qqq' I reach "[1]debug>", but if I check with dbstack, it still tells me that I am at the same "keyboard>" instance.  Then when I do "dbnext", I don't return to the "keyboard>" instance, but return to a "debug>" instance, unless I execute "dbquit", in which case I do go back to a "keyboard>" prompt.

There are bigger issues to tackle and I don't mind leaving this one alone, but the fact that there are so many paths through the code seems unideal.  In another unexpectedness, entering 'qqq' gets you to "[1]debug>" but typing another error such as 'zzz' does not take you to "[2]debug>" which is what I would now expect.  Is the interpreter somehow not incrementing the debug stack when the prompt is the same?

I attached tst_dbp2.m which is the file I am now using for testing which has debug_on_error embedded in it.


(file #47252)

Rik <rik5>
Group administrator
Tue 23 Jul 2019 04:03:33 PM UTC, comment #4: 

Oh, I see, the version you posted in the text of the original submission has a call to set debug_on_error and the one that is attached to the report does not have those first two statements.

In that case, yes, you should expect to enter a new debugger level when the error occurs.  If you type "dbquit" at the "[1]debug> " prompt, you should be back at the "keyboard> " prompt.

So, I think everything is working as I would expect now, but I could still be persuaded that my idea of what the best prompts are here is confusing.

John W. Eaton <jwe>
Group administrator
Tue 23 Jul 2019 03:58:18 PM UTC, comment #3: 

That's strange, and not what I see:


octave:1> __octave_config_info__ ('hg_id')
ans = 6c438195f4e0
octave:2> tst_dbp
stopped in tst_dbp at line 3 [/net/devnull/scratch/jwe/build/octave/tst_dbp.m]

keyboard> qqq
error: 'qqq' undefined near line 1 column 1
error: called from
    tst_dbp at line 3 column 1
keyboard> dbnext
stopped in tst_dbp at line 5 [/net/devnull/scratch/jwe/build/octave/tst_dbp.m]
5: y = 2;
debug> dbcont
octave:3>


I'd like to understand why you see this different behavior because it's not what I expect to happen.

But now I see that your tst_dbp script is stopping at line 6 and mine is stopping at line 3.  The version of this script that you attached to this bug report has the keyboard statement at line 3.  Is your version different from the one posted here?

John W. Eaton <jwe>
Group administrator
Tue 23 Jul 2019 03:41:13 PM UTC, comment #2: 

No idea what Matlab does for this.

Using this tip on the development branch


parent: 27285:6c438195f4e0 tip
 internal documentation for interpreter_events and event_manager classes


I still see that after executing tst_dbp.m and typing "qqq" I get a prompt of "[1]debug".  Maybe I should just live with it.


Rik <rik5>
Group administrator
Tue 23 Jul 2019 01:47:13 AM UTC, comment #1: 

After this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/49c60d16866f

I see


octave:1> tst_dbp
stopped in tst_dbp at line 3 [/net/devnull/scratch/jwe/build/octave-debug/tst_dbp.m]

keyboard> dbstack
stopped in:

  --> tst_dbp at line 3 [/net/devnull/scratch/jwe/build/octave-debug/tst_dbp.m]
keyboard> qqq
error: 'qqq' undefined near line 1 column 1
error: called from
    tst_dbp at line 3 column 1
keyboard> dbstack
stopped in:

  --> tst_dbp at line 3 [/net/devnull/scratch/jwe/build/octave-debug/tst_dbp.m]
keyboard> dbnext
stopped in tst_dbp at line 5 [/net/devnull/scratch/jwe/build/octave-debug/tst_dbp.m]
5: y = 2;
debug> dbcont
octave:2>


What does Matlab use for the debug prompt?  Is it the same as the  prompt when debugging is entered using "keyboard"?

Does Matlab provide any indication that you are in a nested debugging context, other than needing to execute dbquit multiple times (or use "dbquit all") to fully exit back to the top prompt?

I think showing the debug level in the prompt is useful, but we could certainly make it optional and disabled by default if others don't find it useful.  I'd also be fine with using "debug> " for all the debugging prompts instead of attempting to distinguish the REPL that you enter using the keyboard function from other debugging REPLs.

John W. Eaton <jwe>
Group administrator
Fri 12 Jul 2019 10:56:56 PM UTC, original submission:  

The debug prompt can take on different values which seems unnecessary when compared to previous versions of Octave where "debug>" was used all the time.

In the first case, a breakpoint that is hit with the keyword "keyboard" drops the user in to the debugger but the prompt is "keyboard>".  A breakpoint that is set with dbstop drops the user in to the debugger and the prompt is "debug>".

Second, when in debug mode the prompt can change from "keyboard>" to "[1]debug>" to "debug>" all in the same session.

A sample m-file called tst_dbp.m is attached


clear all
debug_on_error (1)

x = 1;

keyboard;

y = 2;


And here is the diary of a session that shows three different debug prompts.


octave:3> tst_dbp
keyboard> dbstack
stopped in:

  --> tst_dbp at line 6 [/home/rik/wip/Projects_Mine/octave-dev/tst_dbp.m]
keyboard> qqq
error: called from
    tst_dbp at line 6 column 1
error: 'qqq' undefined near line 1 column 1
[1]debug> dbstack
stopped in:

  --> tst_dbp at line 6 [/home/rik/wip/Projects_Mine/octave-dev/tst_dbp.m]
[1]debug> dbnext
debug> dbcont
octave:4> diary off



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 #47252:  tst_dbp2.m added by rik5 (62B - text/x-matlab)
file #47204:  tst_dbp.m added by rik5 (26B - 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)
  • -email is unavailable- added by rik5
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2019-07-24 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2019-07-24 jwe StatusNeed Info In Progress
    2019-07-23 rik5 Attached File- Added tst_dbp2.m, #47252
        Priority5 - Normal 3 - Low
    2019-07-23 jwe StatusConfirmed Need Info
    2019-07-12 rik5 Attached File- Added tst_dbp.m, #47204
        Carbon-Copy- Added jwe

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code