[Tcl-bugs] [ tcl-Bugs-1743941 ] TclCheckInterpTraces cycles

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

Bugs item #1743941, was opened at 2007-06-26 21:21
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1743941&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: 45. Traces
Group: obsolete: 8.4.11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yevgen Ryazanov (eugene_cdn)
Assigned to: Don Porter (dgp)
Summary: TclCheckInterpTraces cycles

Initial Comment:
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!


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

>Comment By: Don Porter (dgp)
Date: 2007-06-27 12:51

Message:
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.


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

Comment By: Don Porter (dgp)
Date: 2007-06-27 12:40

Message:
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

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

Comment By: Don Porter (dgp)
Date: 2007-06-26 23:57

Message:
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?



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

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