Tcl Source Code

Tcl Version 8.4.3
OS Platform and Version: windows 2000,linux redhat 7.3

when putting a trace on command execution leave the 
errorInfo and errorCode are not being set properly when 
an error happens in the command being called

proc traceLog {cmd info {result ""} {op ""}} {
puts "----- trace -----"
puts "command: $cmd"
puts "info: $info"
puts "result: $result"
puts "op: $op"
puts "----- leave trace -----"
}
proc test {} {
error "testMsg" "testInfo" "testCode"
}
for {set i 0} {$i<2} {incr i} {
catch {test} msg
puts "message: $msg"
puts "errorInfo: $errorInfo"
puts "errorCode: $errorCode"
unset msg
unset errorCode
unset errorInfo
trace add execution test leave {traceLog}
}

result:

message: testMsg
errorInfo: testInfo
    (procedure "test"
    invoked from with
"test"
errorCode: testCode
----- trace -----
command: test
info: 1
result: testMsg
op: leave
----- leave trace ---
message: testMsg
errorInfo: testMsg
    while executing
"test"
errorCode: NONE

Logged In: YES 
user_id=80530


Fixed for 8.4.5+.

File Added - 63818: 760947-HEAD.patch

Logged In: YES 
user_id=80530

Corresponding patch for the HEAD
must also save/restore return
options (TIP 90).

File Deleted - 63814:

File Added - 63817: 760947.patch

Logged In: YES 
user_id=80530


Revised patch takes more care
to only save/restore the bits
that control error information.
That should ease any safety
concerns (deleted or safe
interps getting modified, etc...)

Logged In: YES 
user_id=148712

Second opinion: I'm pretty sure it does no damage, but I do
not claim to really grok traces . Testsuite seems happy too ...

File Added - 63814: 760947.patch

Logged In: YES 
user_id=80530


Ha!  Yes, that's it.  Just needed
to get the flags right.  Here's a
patch that makes the demo
script act as expected, and
I think it does no damage.
Passing to another maintainer
for a second opinion.

Logged In: YES 
user_id=80530

seems it's even worse that that.
While execution traces are
handled completely within
TclEvalObjvInternal(), the
management of errorCode
and errorInfo is all over the
place, so simple attempt to
fix this do not even work.
The real culprit may be
the Tcl_ResetResult()
embedded inside the execution
of the leave traces, which cause
the errorInfo and errorCode
machinery to get reset,
upsetting the expectations
of the [error] command,
which wants Tcl_LogCommandInfo
to respect the ERR_ALREADY_LOGGED
and ERROR_CODE_SET
flags that it set.

Logged In: YES 
user_id=80530


seems the way to fix this is to
save and restore the values
of ::errorCode and ::errorInfo
around the calling of leave traces.

potential problem is that this
will also cause any read
and write traces on those
variables to fire.

Seems it's not a safe enough
change to explore in time
for 8.4.5.  May need more
detailed sorting out and
testing through 8.5a development.

Logged In: YES 
user_id=80530

updated the docs to be the
same as TIP 62.

Unfortunately, the documented
behavior isn't completely 
possible, and isn't directly
"on point" for this report.

It's not possible, because multiple
execution traces may be set on
a single command, and if more that
one trace raises an error, it's not
possible for all of those error to become
the error of the traced command.

Generally error management during
execution tracing is way under-specified.

The issue in this report deals with a
simpler situation, where the traces
themselves raise no errors, but corrupt
the extra error information produced
by the traced command.

Logged In: YES 
user_id=80530

re-reading this, it seems that comment
in the docs makes either no sense,
or only tautological sense.  In context
"command" refers to the handler command,
not the traced command.  The name of
the traced command is known as "name"
in context.

Ahhh... hold on.  TIP 62 has the correct
specification.  This is a typo in the man page.

Logged In: YES 
user_id=32170

Well, the manpage states (for 'leave' and 'leavestep' traces):

"If an error occurs while executing the command body, then 
the command name as a whole will return that same error."

The result above does look a little peculiar, although I don't 
really know enough about error(Code|Info) to be sure what 
the correct result should be.

In some sense if there's a leave trace on 'foo', then the result 
ought to be nearly identical to that obtained by manually 
replacing every occurrence of 'foo' in one's code by 'foo ; 
tracecmd foo ...'. (Obviously this is complicated by additional 
arguments, and by the cases where foo throws an error itself).

Logged In: YES 
user_id=80530


Can I get another TIP 62 ruling?

Is this intended behavior?