From: SourceForge.net <no...@so...> - 2003-05-12 21:41:03
|
Bugs item #730244, was opened at 2003-04-30 16:34 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=730244&group_id=10894 Category: 44. Parsing and Eval Group: 8.4.2 Status: Open Resolution: None Priority: 5 Submitted By: Don Porter (dgp) Assigned to: miguel sofer (msofer) Summary: missing refCount management in Tcl_EvalObjv Initial Comment: This script panics: interp create i proc test args {puts $args} trace add execution test enter {interp alias i alias {} ;#} interp alias i alias {} test this i eval alias The problem is that TEOVI does not use refCounting to protect the elements of the objv array. So if a trace frees an argument value, that value is not available for command procedure execution. Most TEOVI callers manage refCounts, but Tcl_EvalObjv does not; thus interp alias calls do not. A fix is to add objv refCounting to Tcl_EvalObjv, at an unknown performance cost. Thoughts? ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2003-05-12 22:41 Message: Logged In: YES user_id=79902 Looks like a bug in alias handling to me.The problem is that the deleting of the alias makes the refcounts on the (leading) arguments decrease at an unexpected time, resulting in the refcounts for the command obj dropping to zero before the return of Tcl_EvalObjv (so violating the general contractural principle of Tcl_Eval* functions.) Traces are the most obvious way of triggering this, yes, but I'd hate to swear that that's the only way it could happen. Two ways to fix this: 1) incr the refcounts of the prefix part of the alias command for the duration of the alias call 2) decouple the Alias structure from the alias command lifespan, and use refcounting to delete *that* only when the last reference to it (whether from the command or from the executing instances) goes away. I prefer the second way, but the first would do too. I don't think either will be too expensive in practice. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-04-30 18:58 Message: Logged In: YES user_id=80530 my comment about Tcl_EvalEx's need for refCounts was incorrect. Since it pulls values from the interp result, it needs to claim each one before moving on to do substitutions for the next one. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2003-04-30 17:49 Message: Logged In: YES user_id=148712 The TclInterpReady difference may actually be a bug in TEBC: [Bug 495830] ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-04-30 17:26 Message: Logged In: YES user_id=80530 this issue combined with TclInterpReady checks and numLevels management suggest that the TEOVI callers in tclBasic.c really have different needs from the caller in tclExecute.c. Another level of wrapping could help here. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-04-30 16:51 Message: Logged In: YES user_id=80530 there's any number of solutions, but it's best not to get too tricky, and expecially best not to let the trickiness escape to the public interface. Would be best if each routine in the core managed refCounts according to its own needs rather than serving callers, or called routines. TEOVI is what needs refCounts, to preserve objs across trace and normal execution calls. Tcl_EvalEx, for example, currently does incr/decr of refcounts, even though it doesn't really need to. It does only one thing with objv, pass it in to TEOVI. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2003-04-30 16:40 Message: Logged In: YES user_id=148712 Another fix is to document that TEOV requires that the caller hold a counted reference to its arguments, and insure that all core calls respect this. No performance cost for bytecodes (which do not suffer this problem), more complexity ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=730244&group_id=10894 |