Wed 23 Nov 2016 03:31:23 AM UTC, comment #14:
I verified the fix on stable. Closing report.
|
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...
|
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.
|
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.
|
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.
|
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?
|
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)
|
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
|
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.
|
Fri 18 Nov 2016 06:31:13 PM UTC, comment #5:
Here is a simpler example to demonstrate the error
|
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.
|
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.
|
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.
|
Fri 18 Nov 2016 10:59:32 AM UTC, comment #1:
...tracking down here the bug... => ...tracking down where the bug...
|
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?
|