Tcl Source Code

noted in the chat:

infinite loop:
% proc foo {i args} {namespace eval ::a set [incr i] 1; trace add variable ::a::$i unset [list ::foo $i]}
% foo 0
% info vars a::*
::a::1
% namespace delete a

Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

File Added - 244864: undo.patch

Logged In: YES 
user_id=80530
Originator: YES


This bug is fixed on HEAD.

If it's decided this isn't really
a bug after all, attached patch
will restore this behavior.
File Added: undo.patch

Logged In: YES 
user_id=148712
Originator: NO

The algorithm for variable deletion on namespace death keeps unsetting variables (and running unset traces) until no more are left. It does make sure that a variable cannot revive *itself* (ie, #1746143 is not possible on namespace deletion), but makes otherwise no difference between variables that existed at the time of the [namespace delete] call and those that were created afterwards.

This does look like a bug to me - but I am not sure what the right behaviour would be. One radical solution would be to unhook the ns's variable table before starting to unset, replacing it with an empty one. After unsetting all variables in the main table, the second table would be deleted without running unset traces. Such a thing would change the semantics slightly: no pre-existing variable in this namespace is accessible while var unset traces are running. In contrast, today they may (or may not) be: variables are unset in table order (ie, more or less random), so some of them may still be accessible while others are already gone. Can't imagine much use for this.