bugGNU Octave - Bugs: bug #55178, Improved debug on error behaviour...

 
 

bug #55178: Improved debug on error behaviour inside octave core functions

Submitter:  Georg Wiora <gwiora>
Submitted:  Fri 07 Dec 2018 10:11:45 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  gwiora 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

Mon 22 Nov 2021 04:34:11 PM UTC, comment #27: 

No more complains about similar functions for a week.

Closing report as fixed again.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 12 Nov 2021 01:32:17 PM UTC, comment #26: 

I pushed the following change for assert.

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

Are there any other error-like functions that are implemented in M-files that need similar changes?  If not, then I think we can close this report as fixed.


John W. Eaton <jwe>
Group administrator
Thu 11 Nov 2021 08:00:01 PM UTC, comment #25: 

Hello,

This happens with assert.m as well:


stopped in assert at line 99 [/usr/local/share/octave/7.0.0/m/testfun/assert.m]
99:           error ("assert %s failed", argin);


Adding debug_on_error (false, "local"); line to assert.m at the beginning solves the problem. Please verify.

Anonymous
Wed 10 Nov 2021 03:53:10 PM UTC, comment #24: 

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/63147d7d53a0

Closing report as fixed.

John W. Eaton <jwe>
Group administrator
Wed 10 Nov 2021 02:57:05 PM UTC, comment #23: 

You are right my last results where without your edit. When I apply your patch I get the same results as you do.

It does work from command line and also when needed in a script or function.

I vote +1 for this fix to solve my feature request.

Thanks a lot!

Georg Wiora <gwiora>
Wed 10 Nov 2021 02:28:50 PM UTC, comment #22: 

Oh, nevermind.  It does appear to work for me with 6.x as well.

@gwiora: If you did edit print_usage.m, then make sure you used


debug_on_error (false, "local");


Comment #15 might have been confusing because I used FALSE in the diff but the preceding text had TRUE.  Oops.

John W. Eaton <jwe>
Group administrator
Wed 10 Nov 2021 02:23:35 PM UTC, comment #21: 

I suspect the difference is due to changes in the way errors and debug_on_error are handled in 6.x vs. 7.x.

I'll push my change and you can expect this problem to be fixed in the next major release.

John W. Eaton <jwe>
Group administrator
Wed 10 Nov 2021 02:20:35 PM UTC, comment #20: 

@jwe: Your proposed change works for me on Windows 10 with Octave 6.4.0:

>> debug_on_error (true); plot
C:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\bin\makeinfo: warning: error loading ./Config: Can't locate ./Config at C:\PROGRA~1\GNUOCT~1\OCTAVE~1.0\mingw64\bin\makeinfo line 345.

error: Invalid call to plot.  Correct usage is:

 -- plot (Y)
 -- plot (X, Y)
 -- plot (X, Y, FMT)
 -- plot (..., PROPERTY, VALUE, ...)
 -- plot (X1, Y1, ..., XN, YN)
 -- plot (HAX, ...)
 -- H = plot (...)

Additional help for built-in functions and operators is
available in the online version of the manual.  Use the command
'doc <topic>' to search the manual index.

Help and information about Octave is also available on the WWW
at https://www.octave.org and via the help@octave.org
mailing list.
debug> dbstack
stopped in:

  --> plot at line 220 [C:\Program Files\GNU Octave\Octave-6.4.0\mingw64\share\octave\6.4.0\m\plot\draw\plot.m]


@gwiora: Did you actually edit print_usage.m with the change jwe proposed in comment #15?

Markus Mützel <mmuetzel>
Group administrator
Wed 10 Nov 2021 02:09:45 PM UTC, comment #19: 

Very interesting difference.
With the same setup I get:

debug> dbwhere
stopped in print_usage at line 87 [C:\Program Files\GNU Octave\Octave-6.4.0\mingw64\share\octave\6.4.0\m\help\print_usage.m]

I use brand new octave 6.4.0 installation on windows 7, 64 Bit-System, with an i7 processor. Any idea if this makes a difference to your installation? You seem to be on a unix-kind installation. It may be a windows feature...

Georg Wiora <gwiora>
Wed 10 Nov 2021 01:43:56 PM UTC, comment #18: 

Strange, here is what I see with my proposed change:


octave:1> debug_on_error (true); plot
error: Invalid call to plot.  Correct usage is:

 -- plot (Y)
 -- plot (X, Y)
 -- plot (X, Y, FMT)
 -- plot (..., PROPERTY, VALUE, ...)
 -- plot (X1, Y1, ..., XN, YN)
 -- plot (HAX, ...)
 -- H = plot (...)

Additional help for built-in functions and operators is
available in the online version of the manual.  Use the command
'doc <topic>' to search the manual index.

Help and information about Octave is also available on the WWW
at https://www.octave.org and via the help@octave.org
mailing list.
stopped in plot at line 222 [/net/devtty/scratch/jwe/src/octave/scripts/plot/draw/plot.m]
222:     print_usage ();
debug> dbwhere
stopped in plot at line 222 [/net/devtty/scratch/jwe/src/octave/scripts/plot/draw/plot.m]
debug> dbstack
stopped in:

  --> plot at line 222 [/net/devtty/scratch/jwe/src/octave/scripts/plot/draw/plot.m]


So it seems to work for me.

John W. Eaton <jwe>
Group administrator
Wed 10 Nov 2021 08:46:33 AM UTC, comment #17: 

@mmuetzel comment #14: I totally agree with you that showing the usage information is superior over just throwing an error. If we would step back to just throwing an error this would need a higher level of development on all function to display proper error messages. This is unrealistic (unfortunately).

My intention was to remove an annoying behavior while debugging, especially interactively. It happens quite often that I enter an incorrect statement and then have to close the print_usage window, step up the stack manually to come back to my original position and try again. Just too many steps.

An alternative to my suggestion would be a drop down selector for stack level in the GUI as you proposed in comment #9. I am open for anything that simplifies working with octave.

Georg Wiora <gwiora>
Wed 10 Nov 2021 08:05:43 AM UTC, comment #16: 

Thank you for your nice suggestion John. A good idea but unfortunately not the intended solution.

I tried your patch. It is somewhat nicer because you do not end in this useless print_usage.m file opened in editor. The console output is still the same, but unfortunately the debugger is not entered at all. That means no access to variable contents and no chance to do interactive debugging.

I would not like to deactivate the debugger but rather influence the stack level where it stops.

Georg Wiora <gwiora>
Tue 09 Nov 2021 06:13:47 PM UTC, comment #15: 

Since debug_on_error only stops when executing interpreted code, I was thinking that maybe the best solution was to make print_usage a built-in function.  Then calling it would behave the same as calling error.  But then I remembered that we can use


debug_on_error (true, "local");


to temporarily set the value of debug_on_error inside a function.  So if we do that inside the print_usage function, I think we'll get the desired behavior.  Can you try the following change and see whether it does what you expect?


diff --git a/scripts/help/print_usage.m b/scripts/help/print_usage.m
--- a/scripts/help/print_usage.m
+++ b/scripts/help/print_usage.m
@@ -82,6 +82,7 @@ function print_usage (name)
     warning ("print_usage: raw Texinfo source of help text follows...\n");
   endif

+  debug_on_error (false, "local");
   if (at_toplev)
     error ("Octave:invalid-fun-call",
            "Invalid call to %s.  Correct usage is:\n\n%s\n%s",


John W. Eaton <jwe>
Group administrator
Tue 09 Nov 2021 04:23:10 PM UTC, comment #14: 

I just double-checked in Matlab R2021a. It does stop in its own .m files at errors after `dbstop if error`.
That is consistent with what happens in Octave.

The function `print_usage` is a convenience function that is used in many functions in Octave core and in many packages. It prints the part of the help string that shows the supported calling forms before it raises an error.
As you probably can imagine, the function is used when it is pretty clear that the user called the function in a wrong form.
Telling the user how to call the function instead is actually a nice feature imho.

As far as I can tell, Matlab just emits an error without telling the user which calling forms can be used.

You could probably start a poll on discourse whether Octave should get rid of `print_usage` and instead just throw an error in these cases like Matlab does. But I can already tell you that I personally strongly favor Octave's current behavior.

Markus Mützel <mmuetzel>
Group administrator
Tue 09 Nov 2021 08:26:50 AM UTC, comment #13: 

It is 5 years ago that I used matlab  (2014b). At least I am sure never to be stopped in something like print_usage() but usually at a function call that is not part of the matlab distribution. I even believe to remember that there was some special (undocumented?) command at the beginning of core functions to avoid an error stop inside, something like

onerror return

Current matlab documentation since 2016 does not say anything about this. Sorry that I do not have more information.

Georg Wiora <gwiora>
Tue 09 Nov 2021 07:50:34 AM UTC, comment #12: 

Are you sure Matlab handles errors in core functions differently?
Last time I checked, you'd be dropped into core functions (if they are .m code) just like in Octave...

Markus Mützel <mmuetzel>
Group administrator
Mon 08 Nov 2021 05:12:43 PM UTC, comment #11: 

Thanks for asking me to contribute actively. My involvement and my energy budget does not allow me to enter this project in an active role. I can contribute on the level I did and give something back to this great project that really improves my work, but not more. Sorry for that.

I was inspired to this proposal by the way matlab does handle errors in core functions and in packet functions: The error message is issued on the line the user code calls the code function and not inside the method. This really improves the development process. And in my experience these kind of errors do not only occur in the early development stage but also during interactive development/debugging and data analysis. This is maybe the most annoying case, because while stopped at a break point, a wrong command call on the command line brings the debugger in an unwanted stack position. I have to dbup until I get back to my original position and can try again with the correct command.

I understand that there are different possibilities in the rating of this proposal. It may not be the most important improvement, but for me it would resolve a source of permanent annoyance during octave code development. Thanks for your support.

Georg Wiora <gwiora>
Mon 08 Nov 2021 04:59:41 PM UTC, comment #10: 

@gwiora: Thanks for the example in file #52223) comment #6 🙂👍

From a user perspective the point where the debugger stops does not make super much sense in my opinion either.

However, you would only stop in "print_usage" when you really screwed up a function call (which is most likely only once during the early development stage of a function).

Thus it might be an item, "not annoying enough" to care about.  The casual Octave user might be unaffected, as they do not user "debug_on_error" by default.  At lease I did not stumble over this very often 😇

By the current design of "print_usage" as m-file, I do not see much potential for improving the situation easily.

Something like "evalin ('caller', 'error (...)')" will not work.

I see the original idea of this function: something like "error", but with an automatic descriptive message provided by the calling functions doc string.

Maybe you can start by refactoring "print_usage" in C++ by looking at error()

https://hg.savannah.gnu.org/hgweb/octave/file/cf434923aec0/libinterp/corefcn/error.cc#l1177

and change the way the error message is created.

Are you interested in workin on this? 🙂

Kai Torben Ohlhus <siko1056>
Group Member
Mon 08 Nov 2021 03:41:39 PM UTC, comment #9: 

Imho, it would be confusing if the `error` function would behave differently depending of in which function it is called. At the moment its behavior is pretty clear and makes sense to me: The error stack is from where the `error` function is called.

Maybe some kind of code analysis tool could point to a probable cause of an error. I guess that is what you are interested in? If you'd like to implement a (static) code analyzer for Octave, please give it a try.

Some time ago, someone mentioned adding a GUI element that would allow an easy traversal of the error stack. Maybe that would somewhat alleviate this issue.

Markus Mützel <mmuetzel>
Group administrator
Mon 08 Nov 2021 02:08:03 PM UTC, comment #8: 

Yes, the output is correct, but it does not make sense. The cause of the error is in

 dbtestfunc at line 9 [Z:\Software\DebugTest.m]


The stack pointer should be placed there to help identifying the cause of the error. This was the target of my initial proposal.

Georg Wiora <gwiora>
Mon 08 Nov 2021 12:24:11 PM UTC, comment #7: 


> The debugger stops in "print_usage" function instead of where the "error" command is called.


What do you mean by this? The error is thrown in `print_usage` at line 98:
http://hg.savannah.gnu.org/hgweb/octave/file/869dea2b5c91/scripts/help/print_usage.m#l98

    error ("Octave:invalid-fun-call", msg);


The output of `dbstack` is correct.

Markus Mützel <mmuetzel>
Group administrator
Mon 08 Nov 2021 09:54:43 AM UTC, comment #6: 

Please use (file #52223) for testing. (file #52222) does not work.

Georg Wiora <gwiora>
Mon 08 Nov 2021 09:27:20 AM UTC, comment #5: 

This problem may be related to the implementation of error command.
I have created a test case calling imresize() in image package with illegal parameters. The debugger stops in "print_usage" function instead of where the "error" command is called. Just run the file and enter


> dbstack

  --> print_usage at line 98 [C:\Program Files\GNU Octave\Octave-6.3.0\mingw64\share\octave\6.3.0\m\help\print_usage.m]
         imresize at line 64 [C:\Program Files\GNU Octave\Octave-6.3.0\mingw64\share\octave\packages\image-2.12.0\imresize.m]
       dbtestfunc at line 9 [Z:\Software\DebugTest.m]
        DebugTest at line 13 [Z:\Software\DebugTest.m]


I would like to see this result instead:

> dbstack

  --> imresize at line 64 [C:\Program Files\GNU Octave\Octave-6.3.0\mingw64\share\octave\packages\image-2.12.0\imresize.m]
       dbtestfunc at line 9 [Z:\Software\DebugTest.m]
        DebugTest at line 13 [Z:\Software\DebugTest.m]



(file #52222)

Georg Wiora <gwiora>
Sun 07 Nov 2021 12:42:48 AM UTC, comment #4: 

This is a bit like if you ask Google Maps or equivalent for a route and the first 5 instructions are about how to leave your own neighborhood.

Would it help if debug were to call dbup 2 or 3 times automatically? That will get it from utility functions to the user's own code.

Anonymous
Sat 06 Nov 2021 06:56:59 AM UTC, comment #3: 

Can you give a concrete step-by-step example how to provoke the error situation where "debug_on_error" behaves "undesired" and describe how you expect it to work?

Kai Torben Ohlhus <siko1056>
Group Member
Fri 05 Nov 2021 10:18:01 AM UTC, comment #2: 

Is there any interest in realizing this request in future releases? I still would love to see it!

Georg Wiora <gwiora>
Thu 13 Dec 2018 05:27:01 PM UTC, comment #1: 

+1

I'm also thrown regularly in e.g., print_usage.m or cellfun.m and have to do one or more dbup's to get into my own code where the error was provoked.  Plus, close e.g., print_usage.m and /or cellfun.m that have been opened in the editor.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 07 Dec 2018 10:11:45 AM UTC, original submission:  

Feature request

I recommend changing the behavior of the debug_on_error() method inside octaves core functions in a way similar to matlab.

When debug_on_error is activated in matlab and an error appears inside a core function, the debugger stops at the calling function in the user code. In the same situation Octave stops inside the core function even when the core function calls error() to produce a message. This is very annoying during debugging user functions. I like to have debug_on_error() activated permanently, because it is so useful.

Currently the side effect of activating debug_on_error is, that every syntax error and wrong command causes the "print_usage" function to be opened in the editor and debugger is stopping there. This is not what I need as octave user.



Suggested solution

Every core function (and probably as a recommendation also packet functions) should have as first command:


  # enable return to caller on error
  return_and_stop_on_error (true);


This should remove the top stack frame and stop the debugger in the callers function at least when the called function actively issues an error().

There could be an additional global signal to enable core function debugging.

Georg Wiora <gwiora>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #52223:  DebugTest.m added by gwiora (334B - application/octet-stream - Corrected file to provoke error.)
file #52222:  DebugTest.m added by gwiora (364B - application/octet-stream - File provoking an error as test case)

 

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 mmuetzel (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by gwiora (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-22 siko1056 StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2021-11-12 siko1056 StatusFixed Need Info
        Open/ClosedClosed Open
    2021-11-10 jwe StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2021-11-08 gwiora Attached File- Added DebugTest.m, #52223
    2021-11-08 gwiora Attached File- Added DebugTest.m, #52222
    2021-11-06 siko1056 StatusNone Need Info
        Release4.4.1 dev

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code