Tcl Source Code

OS: Solaris 9, Linux RH 4U3

On certain order of two Tcl_CreateTrace calls, TclCheckInterpTraces never returns on evaluation of a non-trivial commands. Certain order is first trace is of depth "1", and second one is of depth "5" or more on Solaris and "1" on Linux. It cycles in this loop
   for ( tracePtr = iPtr->tracePtr;
      (traceCode == TCL_OK) && (tracePtr != NULL);
           tracePtr = active.nextTracePtr) {
with the same value of tracePtr.

Expected behavior: should not cycles.

See attached testcase. Need to build it
   gcc -o libtrace.so -g -shared -fPIC trace.c -I...
and then
   > tclsh
   tclsh> load libtrace.so
After a while it hangs. If you switch the order (depth) of traces, it works on Solaris.
It does not matter which file to evaluate. It must be non-trivial.
Good luck!

Logged In: YES 
user_id=80530
Originator: NO


fixes committed on both active branches.

File Deleted - 234785: 



File Added - 234794: 1743941.patch

Logged In: YES 
user_id=80530
Originator: NO


New patch includes test suite addition.
File Added: 1743941.patch

Logged In: YES 
user_id=80530
Originator: NO


ok, I think I recall now.

This is a symptom of some
really bad implementation choices
made in the creation of the *step
execution traces.  Rather than
an orthogonal implementation, those
got done through some ugly surgery
grafting them into the Tcl_CreateTrace
traces, and apparently damaging those
at the same time.

I guess it's an indicator how infrequently
used the Tcl_CreateTrace call is that we
only get a report on this now.

File Added - 234785: 1743941.patch

Logged In: YES 
user_id=80530
Originator: NO


found some unexpected time...

Problem is in the code that
implements reversing the order
of traces for the "enterstep" call.

When the level is too low for the
trace to fire, a "continue" restarts
the loop before "lastTracePtr" gets set
to the right value for proceeding.

So, an effective fix is pretty simple.
Less clear and more troubling is why a
lot of this code is there in the first
place.  Still looking into that.

Attached is a patch against Tcl 8.4.15.


File Added: 1743941.patch

Logged In: YES 
user_id=80530
Originator: NO


Reproduced.  Won't have time to really
dig in and fix this for at least a few days.

Meanwhile is might be interesting to see
how far back this problem goes.  Did Tcl 7
suffer the same issue, or is this a regression
sometime since then?

File Added - 234686: trace.c