[Tcl-bugs] [ tcl-Bugs-1338280 ] unset traces during namespace delete misbehave
by SourceForge.net other posts by this author
Oct 31 2005 9:04PM messages near this date
[Tcl-bugs] [ tcl-Bugs-1338280 ] unset traces during namespace delete misbehave
|
[Tcl-bugs] [ tcl-Bugs-1338280 ] unset traces during namespace delete misbehave
Bugs item #1338280, was opened at 2005-10-26 05:53
Message generated for change (Comment added) made by dgp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1338280&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.4.11
Status: Open
Resolution: None
Priority: 9
Submitted By: miguel sofer (msofer)
Assigned to: miguel sofer (msofer)
Summary: unset traces during namespace delete misbehave
Initial Comment:
(neuronstorm reports in clt:
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/91073af364234a81/3a1aa30e489f
3eb0#3a1aa30e489f3eb0
The following script demonstrates an invalid result
(empty string element in list) from [info vars
?pattern?] during unset traces called during [namespace
delete].
----
namespace eval ::ref {}
set ::ref::var1 AAA
trace add variable ::ref::var1 {unset} [list doTrace]
set ::ref::var2 BBB
trace add variable ::ref::var2 {unset} [list doTrace]
proc doTrace {vtraced vidx op} {
puts stdout "'[info vars ::ref::*]'"
}
namespace delete ::ref
puts stdout "'[info vars ::ref::*]'"
----
Output on windows Tcl 8.5a4 is:
'::ref::var1 ::ref::var2'
'{} ::ref::var2'
''
Output on windows Tcl 8.4.5 is:
'::ref::var1 ::ref::var2'
'::ref::var2'
''
Tcl8.4.7 behaves like 8.4.5, core-8-4-branch like 8.5a4
----------------------------------------------------------------------
> Comment By: Don Porter (dgp)
Date: 2005-10-31 23:26
Message:
Logged In: YES
user_id=80530
the patch does introduce a
script-visible change, yes.
it's also a simple change
that fixes this bug and
allegedly 1337229.
Neither the tcl nor the
tcllib test suite care about
the change.
If something does care, then
let's think harder about this, but
not until we find something that
does care.
Crafting a fix for these bugs other
than the one attached here will
be very, very tricky indeed. Unless
we delay variable unset traces until
the point where the namespace
variables are no longer accessible,
then the access must go somewhere,
and we're left with the recursive task
of cleaning *that* up.
I fear we may already have that
problem with command delete traces.
----------------------------------------------------------------------
Comment By: miguel sofer (msofer)
Date: 2005-10-31 16:45
Message:
Logged In: YES
user_id=148712
Patch not committed: it contradicts the comment in
TclTeardownNamespace:
/*
* Start by destroying the namespace's variable table,
* since variables might trigger traces.
*/
In particular, the patch changes the behaviour of the script:
namespace eval a {
proc p {} {puts hi}
trace add variable x unset {a::p;#}
set x 1
}
namespace delete a
which prints 'hi' before the patch, and does not after the
patch. Note that these comments in the source are the only
documentation about the ordering of operations during
namespace deletion.
----------------------------------------------------------------------
Comment By: Don Porter (dgp)
Date: 2005-10-31 14:25
Message:
Logged In: YES
user_id=80530
attached patch corrects the reported
problem and passes the test suite.
----------------------------------------------------------------------
Comment By: miguel sofer (msofer)
Date: 2005-10-29 15:02
Message:
Logged In: YES
user_id=148712
The fundamental problem is that, when a variable is unset
due to its namespace being deleted, the variable exists
while the unset trace is running:
namespace eval a {trace add variable x unset {puts [catch
{set ::a::x}];#}; set x 1}
1
% unset a::x
1
% namespace eval a {trace add variable x unset {puts [catch
{set ::a::x}];#}; set x 1}
1
% namespace delete a
0
This is a very old bug - just verified that Tcl8.3.4 has it
too. It is probably also the cause of Bug 1337229.
----------------------------------------------------------------------
Comment By: miguel sofer (msofer)
Date: 2005-10-29 14:58
Message:
Logged In: YES
user_id=148712
As the order in which the variables are deleted is not
specified, this script has been modified an added to the
testsuite as Test trace-18.4:
namespace eval ::ref {}
set ::ref::var1 AAA
trace add variable ::ref::var1 unset doTrace
set ::ref::var2 BBB
trace add variable ::ref::var2 {unset} doTrace
proc doTrace {vtraced vidx op} {
global info
append info [catch {set ::$vtraced}][llength [info vars
::ref::*]]
}
set info {}
namespace delete ::ref
rename doTrace {}
set info
Note that the returned value is 0201 up to 8.4.7, and 0202
for HEAD and 8-4-branch.
Note also that the *correct* return value is 1110 - as a
variable should not exist when it's unset trace is running.
----------------------------------------------------------------------
Comment By: miguel sofer (msofer)
Date: 2005-10-26 08:52
Message:
Logged In: YES
user_id=148712
On the basis of which versions are buggy, this is presumed
to be caused by the 2004-05-22 commit.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1338280&group_id=10894
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Tcl-Bugs mailing list
Tcl-Bugs@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-bugs
Thread:
SourceForge.net
SourceForge.net
SourceForge.net
SourceForge.net
SourceForge.net
SourceForge.net
SourceForge.net
|