From: SourceForge.net <no...@so...> - 2010-07-31 16:42:03
|
Bugs item #3037525, was opened at 2010-07-31 10:39 Message generated for change (Comment added) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3037525&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: 07. Variables Group: current: 8.5.8 Status: Open Resolution: None Priority: 9 Private: No Submitted By: miguel sofer (msofer) Assigned to: miguel sofer (msofer) Summary: crash when freeing locals hashtable Initial Comment: The one-liner proc foo {} { [catch {upvar 0 dummy \$index}] } ; foo accesses freed memory and causes a crash (in non-threaded tcl, threaded seems to survive due to allocator differences). Valgrind shows that a freed hash entry is being accessed, in order to free it again. The problem seems to depend on the order in which TclDeleteVars traverses the hashtable of locals. Note that this likely impacts 8.6 too (unverified as of yet, time is so short and this netbook so slow). ---------------------------------------------------------------------- >Comment By: miguel sofer (msofer) Date: 2010-07-31 13:42 Message: Two possible solutions: (1) lose the optimisation, delete the vars from the table one by one (just like in TclDeleteNamespaceVars; can also merge big parts of these two funcs) (2) somehow signal to UnsetVarStruct or CleanupVar that the var should NOT be deleted. (2) seems hacky to me, and the value of the opt is iffy anyway (in my prejudice): it is low impact, and only concerns procs with runtime-created locals ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-07-31 11:25 Message: Supporting evidence for the diagnose: % proc foo {} { [catch {upvar 0 dummy \$index; set dummy 1}]}; foo invalid command name "0" % proc foo {} { [catch {upvar 0 dummy \$index; set x 1}]}; foo Segmentation fault ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-07-31 10:58 Message: Description of the early-freeing scenario: * two locals a and b defined at runtime - ie, in the hashtable and not the locals array * upvar 0 a b * the ONLY reference to a is by the upvar, and it remains undefined * the hashtable traversal reaches b before a In this case, when b is freed a is eliminated from the hashtable and is freed too: there are only two refcounts to this var, one from the hash entry and one from the upvar. When the upvar goes away, the undef'ed var is seen as being kept alive only by the entry, and the lot is freed to eliminate the "circular ref". Later, when Tcl_NextHashEntry tries to read a's entry we access freed memory. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-07-31 10:40 Message: OOPS ... forgot to credit tclguy and aku for detecting the problem, and reducing it to this oneliner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3037525&group_id=10894 |