From: SourceForge.net <no...@so...> - 2007-06-27 17:37:19
|
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: Closed >Resolution: Fixed 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 13:37 Message: Logged In: YES user_id=80530 Originator: NO fixes committed on both active branches. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2007-06-27 13:25 Message: Logged In: YES user_id=80530 Originator: NO New patch includes test suite addition. File Added: 1743941.patch ---------------------------------------------------------------------- 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 |