bugGNU Octave - Bugs: bug #49642, rethrow (lasterror ()) loses stack...

 
 

bug #49642: rethrow (lasterror ()) loses stack information from previous error structure

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Fri 18 Nov 2016 09:10:25 AM UTC  
 
Category: InterpreterSeverity: 4 - Important
Priority: 5 - NormalItem Group: Regression
Status: FixedAssigned to: None
Originator Name: Philip NienhuisOpen/Closed: Closed
Release: 4.2.0Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Wed 23 Nov 2016 03:31:23 AM UTC, comment #14:

I verified the fix on stable. Closing report.

Rik <rik5>
Project Administrator
Tue 22 Nov 2016 09:33:03 PM UTC, comment #13:

I checked in the following changeset on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/1d3d0321bc5d

This was a bit more complicated than it should have been and things are still a bit of a mess in error.cc. There are too many things that have side effects in there...

John W. Eaton <jwe>
Project Administrator
Mon 21 Nov 2016 07:10:44 PM UTC, comment #12:

I didn't take it as a complaint.

I'll try to look at this some more this afternoon.

John W. Eaton <jwe>
Project Administrator
Mon 21 Nov 2016 05:36:19 PM UTC, comment #11:

Sorry if my test came across as complaining. This definitely preserves the call stack which is most important. The printing of just a single bit of the error stack seems to be in Frethrow itself. We probably just need to figure out either the right internal function to call that iterates over the stack, or have a for loop in Frethrow over the whole stack.

Rik <rik5>
Project Administrator
Mon 21 Nov 2016 03:34:47 PM UTC, comment #10:

I don't think it's correct for the rethrow of the lasterror to print something different. Probably the message should be constructed in the same way from the stack info in both cases. That's something additional that I would like to fix. But at least this minimal patch does preserve the stack info across the call to rethrow.

John W. Eaton <jwe>
Project Administrator
Mon 21 Nov 2016 06:02:48 AM UTC, comment #9:

I tested the quick patch on stable and it seems to work. One thing I did notice is that when the error is rethrown the printed stack depth is only one deep. In the original error, it includes the functions validsetargs and union. In the subsequent rethrow, it only includes validsetargs. Is that correct?

Rik <rik5>
Project Administrator
Sun 20 Nov 2016 07:42:58 PM UTC, comment #8:

Here's a minimal patch that could probably go on stable. I can see a few other improvements that could be made, but this may be enough for 4.2.1. If it works for you, then I'll push it with a proper commit message.

(file #39032)

John W. Eaton <jwe>
Project Administrator
Sun 20 Nov 2016 06:17:21 PM UTC, comment #7:

It looks to me like error_1 always ends with "throw" so it won't return.

I'll look at how to reorganize this properly given the change from the global error_state variable to using exceptions.
f

John W. Eaton <jwe>
Project Administrator
Fri 18 Nov 2016 07:21:34 PM UTC, comment #6:

The problem is in error.cc in Frethrow. The code is

I added simple printf debug code and the internal call to rethrow_error never returns to this function. That means Vlast_error_stack is not re-initialized. The code for rethrow_error is

I tried removing the NO_RETURN attribute on error_1 but that didn't help.

I'm adding jwe to the CC list since I'm at a loss.

Rik <rik5>
Project Administrator
Fri 18 Nov 2016 06:31:13 PM UTC, comment #5:

Here is a simpler example to demonstrate the error

Mike Miller <mtmiller>
Project Administrator
Fri 18 Nov 2016 06:27:15 PM UTC, comment #4:

Then it looks like this is about

losing all of the stack information from the lasterror structure. According to https://www.mathworks.com/help/matlab/ref/rethrow.html the stack of the error structure is supposed to be reinstated at the point when rethrow is called, and that doesn't seem to be happening. This did work in 4.0.3, so marking as a regression.

Mike Miller <mtmiller>
Project Administrator
Fri 18 Nov 2016 04:45:03 PM UTC, comment #3:

I hit it with installing an OF package from after your cset
http://hg.savannah.gnu.org/hgweb/octave/rev/093b49ac544e
("Capitalize ....")

If you simply hg update to -say- 4a31bd79d7e8 ("maint: Correct spacing...") and then try to install octclip:

pkg install -forge -verbose octclip

you'll see it happening right away.
But of course the next issue is that the error is in a try-catch so debug_on_error(1) actually gets triggered in the catch clause when lasterr is rethrown. (I did use debug_on_error(1) initially.)

And that may be a clue - it could be that the try-catch hides errors happening inside the try clause and as a consequence obfuscates the backtrace.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 18 Nov 2016 04:27:05 PM UTC, comment #2:

Can you create a simple test case and tar up the directory and files and attach it to this bug report?

Also, what does this return

I want to know if the backtrace stack is correct, but error() just isn't reporting it, or if the problem is deeper.

Rik <rik5>
Project Administrator
Fri 18 Nov 2016 10:59:32 AM UTC, comment #1:

...tracking down here the bug... => ...tracking down where the bug...

Philip Nienhuis <philipnienhuis>
Project Member
Fri 18 Nov 2016 09:10:25 AM UTC, original submission:

Revisiting big #49635, an issue that hindered effective tracking down here the bug occurred was that the error traceback was incomplete (stanza for convenience repeated from bug report 49635):

while the actual error occurred in
./pkg/private/default_prefix.m (not mentioned, but correct line number in traceback)
called from:
./pkg/private/install.m >subfunction> create_pkgadddel (not mentioned)
called from:
./pkg/private/install.m (mentioned fine, "correct"[*] line no.).

Maybe this is due to default_prefix being called from a subfunction of another private function?

[*]
Another issue is that the line number in install.m is "correct" in the sense that it is the line number where
"rethrow (lasterror())"
is called. But the actual error occurred in a function call on L.228. IOW, this is a bit deceiving.
Is there a way to uncover the actual line number where an error occurred when calling rethrow?

Philip Nienhuis <philipnienhuis>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #39032:  diffs.txt added by jwe (3KiB - text/plain)

 

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 rik5
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by philipnienhuis (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 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 23 Nov 2016 03:31:23 AM UTCrik5StatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Mon 21 Nov 2016 06:02:48 AM UTCrik5StatusConfirmed=>In Progress
    Sun 20 Nov 2016 07:42:58 PM UTCjweAttached File-=>Added diffs.txt, #39032
    Fri 18 Nov 2016 07:21:34 PM UTCrik5Carbon-Copy-=>Added jwe
    Fri 18 Nov 2016 06:28:54 PM UTCmtmillerStatusNeed Info=>Confirmed
    Fri 18 Nov 2016 06:28:49 PM UTCmtmillerSeverity3 - Normal=>4 - Important
      Releasedev=>4.2.0
      SummaryTraceback from errors in private functions is incomplete=>rethrow (lasterror ()) loses stack information from previous error structure
    Fri 18 Nov 2016 06:27:15 PM UTCmtmillerItem GroupIncorrect Result=>Regression
    Fri 18 Nov 2016 04:27:05 PM UTCrik5StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1