[Tcl-bugs] [ tcl-Bugs-1522803 ] wrong backtrace on arithmetic error

[SourceForge.net <no...@so...>]

Bugs item #1522803, was opened at 2006-07-14 17:35
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1522803&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 44. Parsing and Eval
Group: current: 8.5a4
Status: Open
Resolution: None
Priority: 7
Submitted By: Kevin B KENNY (kennykb)
Assigned to: Don Porter (dgp)
Summary: wrong backtrace on arithmetic error

Initial Comment:
On an arithmetic error, such as division by zero,
the backtrace in ::errorInfo shows the last previous
error, rather than the current error.

Behold:

% catch {unset foo(bar)}; set c 0; expr {1/$c}
divide by zero
% set errorInfo
can't unset "foo(bar)": no such variable
    while executing
"unset foo(bar)"
    invoked from within
"expr {1/$c}"

I'm looking at this briefly, but don't expect
to solve it quickly, and hope that one of the
other developers that understands the bytecode
engine might have a keener insight.

----------------------------------------------------------------------

>Comment By: Don Porter (dgp)
Date: 2006-07-17 23:16

Message:
Logged In: YES 
user_id=80530


Making that same conversion
on core-8-4-branch leads to
the same bug, even though no
ERR_ALREADY_LOGGED reform
was done on that branch.

The real cause is the loss
of several Tcl_ResetResult()
calls in the bytecode execution
engine that had real useful 
flag clearing effects in addition
to initializing an empty result
to append to.

Simple fix is to put them all back.
Better fix might be to find where
one call might go to get the function
done where it's needed.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2006-07-17 23:08

Message:
Logged In: YES 
user_id=80530


Between revisions 1.153 and
1.154 of tclExecute.c, there
were several conversions like:

-    Tcl_ResetResult(interp);
-    Tcl_AppendToObj(Tcl_GetObjResult(interp), "divide by
zero", -1);
+    Tcl_SetObjResult(interp, Tcl_NewStringObj("divide by
zero", -1));

The loss of the Tcl_ResetResult()
call means the loss of a clearing
of the ERR_ALREADY_LOGGED flag,
leading to the observed bug.

This may just be the exposing trigger
with the real cause the E_A_L reform
that happened earlier.  still examining...


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2006-07-17 15:54

Message:
Logged In: YES 
user_id=80530


To demo in a non-interactive
shell, use the script:

  set c 0
  if 1 {
    catch {set foo}
    expr {1/$c}
  }

The interactive / non-interactive
is just a proxy for compiled /
direct evaluation, and its
bytecompilation one must force
to demo the bug.

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2006-07-17 13:41

Message:
Logged In: YES 
user_id=99768

I confirm that it fails only in an interactive interpreter.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2006-07-17 13:07

Message:
Logged In: YES 
user_id=80530


can someone confirm this
problem only shows up in
an interactive interp?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1522803&group_id=10894