[Tcl-bugs] [ tcl-Bugs-1655294 ] command found in deleted namespace

[SourceForge.net <no...@so...>]

Bugs item #1655294, was opened at 2007-02-08 15:17
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1655294&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: 21. [namespace]
Group: obsolete: 8.4.15
>Status: Closed
Resolution: None
Priority: 6
Private: No
Submitted By: Don Porter (dgp)
Assigned to: Don Porter (dgp)
Summary: command found in deleted namespace

Initial Comment:

I don't like the looks of this:

% namespace eval x {
    proc die {} {namespace delete [namespace current]}
    proc test {} {
        set self [namespace which [lindex [info level 0] 0]]
        set ns [namespace qualifiers $self]
        puts "I am $self in namespace $ns which exists? [namespace exists $ns]"
    }
}
% namespace eval x {
    die
    test
}
I am ::x::test in namespace ::x which exists? 0

Once a namespace is deleted, I'd expect us
not to find the commands in it anymore.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-04-26 03:20

Message:
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).

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-01-05 22:19

Message:
Uh ... I wasn't very clear on that. Bug 2724403 had two ways of being
fixed: #1 was by altering the ns deletion sequence, #2 by giving coros a
special treatment. That bug was fixed in HEAD using #2, which has no effect
on the issue in this ticket. The patch attached to that bug report (and NOT
applied) uses approach #1 and should fix the present issue too.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2010-01-05 21:51

Message:

I'm missing something?

Bug 2724403 is Closed:Fixed, but I still
see the demo script in this report producing
the same arguably buggy results on the Tcl HEAD.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-01-03 20:38

Message:
see patch at [Bug 2724403], which redefines the ns deletion sequence and
fixes this: 
"Patch attached with new ns deletion policy: everything goes at once!
Flag bits NS_DYING and NS_DEAD are removed, nsPtr->activationCount is
history too. References are now all kept in nsPtr->refCount: nsName objs,
CallFrames, parent namespace."

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2009-05-03 16:26

Message:
See also #2785893 and #2724403

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2007-09-10 00:22

Message:
Logged In: YES 
user_id=148712
Originator: NO

Your expectations collide with what is coded, apparently by design. The
namespace ::x does not die when [namespace delete ::x] returns, but rather
when the last CallFrame using ::x is popped; the comments at tclNamesp.c
line 588 describe that:

/*
 * If the namespace is on the call frame stack, it is marked as "dying"
 * (NS_DYING is OR'd into its flags): the namespace can't be looked up
 * by name but its commands and variables are still usable by those
 * active call frames. When all active call frames referring to the
 * namespace have been popped from the Tcl stack, Tcl_PopCallFrame will
 * call this procedure again to delete everything in the namespace.
 * If no nsName objects refer to the namespace (i.e., if its refCount 
 * is zero), its commands and variables are deleted and the storage for
 * its namespace structure is freed. Otherwise, if its refCount is
 * nonzero, the namespace's commands and variables are deleted but the
 * structure isn't freed. Instead, NS_DEAD is OR'd into the structure's
 * flags to allow the namespace resolution code to recognize that the
 * namespace is "deleted". The structure's storage is freed by
 * FreeNsNameInternalRep when its refCount reaches 0.
 */


Note that this might just be a bug in [namespace which], it seems to be
otherwise respected:

% namespace eval x {die; ::x::test}
invalid command name "::x::test"

This being said: the precise going-ons on namespace deletion, especially
wrt to the interplay with active call frames and deletion traces, is not
specified anywhere but in code comments. Hard to say how much is really by
actual design, as opposed to a least-bad judgment at the time it was coded.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2007-02-08 21:34

Message:
Logged In: YES 
user_id=80530
Originator: YES


Here's a patch against
core-8-4-branch that I'd like
some opinions about.
File Added: 1655294.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1655294&group_id=10894