Tcl Source Code

Logged In: YES 
user_id=148712

The bug is present in both HEAD and tcl-core-8-4-branch

Logged In: NO 

Here is the output I (Arjen) got on a machine running RH:

(gdb) run
Starting program: tclsh8.4
% namespace eval ns {}
% trace add variable ::ns::var {unset} [list unset ::ns::var #;]
% namespace delete ::ns
Tcl_EventuallyFree called twice for 0x8053e78


Program received signal SIGABRT, Aborted.
0xb7401cef in raise () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7401cef in raise () from /lib/tls/libc.so.6
#1  0xb74034f5 in abort () from /lib/tls/libc.so.6
#2  0xb75b4143 in Tcl_PanicVA () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#3  0xb75b4166 in Tcl_Panic () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#4  0xb75babe6 in Tcl_EventuallyFree () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#5  0xb757e648 in TraceVarProc () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#6  0xb75c8909 in CallVarTraces () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#7  0xb75c8d81 in TclDeleteVars () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#8  0xb75af1e1 in TclTeardownNamespace () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#9  0xb75af035 in Tcl_DeleteNamespace () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#10 0xb75b0ecb in NamespaceDeleteCmd () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#11 0xb75b0891 in Tcl_NamespaceObjCmd () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#12 0xb756d5d9 in TclEvalObjvInternal () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#13 0xb759012c in TclExecuteByteCode () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#14 0xb758f5f6 in TclCompEvalObj () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#15 0xb756e497 in Tcl_EvalObjEx () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#16 0xb759bb7e in Tcl_RecordAndEvalObj () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#17 0xb75ae34e in Tcl_Main () 
from /p/delft3d/users/markus/tcl84-linux/lib/libtcl8.4.so
#18 0x080486b7 in main ()
(gdb)

Logged In: YES 
user_id=585068

This is In NetBSD with an --enable-symbols=all build of the
HEAD (miguel requested this, because his system has stack
corruption.)
(gdb) bt
#0  0x4819cfeb in kill () from /usr/lib/libc.so.12
#1  0x48211a47 in abort () from /usr/lib/libc.so.12
#2  0x4810db3b in Tcl_PanicVA (
    format=0x481571e0 "Tcl_EventuallyFree called twice for
0x%x\n", 
    argList=0xbfbfe454 "HB\026Hxå¿¿s½\022H \213\006\b\003")
    at ../tcl/generic/tclPanic.c:103
#3  0x4810db67 in Tcl_Panic (
    format=0x481571e0 "Tcl_EventuallyFree called twice for
0x%x\n")
    at ../tcl/generic/tclPanic.c:130
#4  0x4811997f in Tcl_EventuallyFree (clientData=0x8068ba0,
freeProc=0x3)
    at ../tcl/generic/tclPreserve.c:295
#5  0x4812bd73 in TraceVarProc (clientData=0x8068ba0,
interp=0x804f020, 
    name1=0x8098620 "::ns::var", name2=0x0, flags=192)
    at ../tcl/generic/tclTrace.c:1998
#6  0x4812c4f4 in TclCallVarTraces (iPtr=0x804f020,
arrayPtr=0x0, 
    varPtr=0x80660a0, part1=0x8098620 "::ns::var",
part2=0x0, flags=192, 
    leaveErrMsg=0) at ../tcl/generic/tclTrace.c:2557
#7  0x481361cf in TclDeleteVars (iPtr=0x804f020,
tablePtr=0x805f6b8)
    at ../tcl/generic/tclVar.c:4018
#8  0x481025a7 in TclTeardownNamespace (nsPtr=0x805f620)
    at ../tcl/generic/tclNamesp.c:1027
#9  0x481024c3 in Tcl_DeleteNamespace (namespacePtr=0x805f620)
    at ../tcl/generic/tclNamesp.c:951
---Type <return> to continue, or q <return> to quit---
#10 0x48105004 in NamespaceDeleteCmd (dummy=0x0,
interp=0x804f020, objc=3, 
    objv=0x8053024) at ../tcl/generic/tclNamesp.c:3303
#11 0x48104626 in Tcl_NamespaceObjCmd (clientData=0x0,
interp=0x804f020, 
    objc=3, objv=0x8053024) at ../tcl/generic/tclNamesp.c:2930
#12 0x480874fd in TclEvalObjvInternal (interp=0x804f020,
objc=3, 
    objv=0x8053024, command=0x0, length=0, flags=0)
    at ../tcl/generic/tclBasic.c:3379
#13 0x480c6147 in TclExecuteByteCode (interp=0x804f020,
codePtr=0x804bb20)
    at ../tcl/generic/tclExecute.c:1843
#14 0x480c4172 in TclCompEvalObj (interp=0x804f020,
objPtr=0x806a020)
    at ../tcl/generic/tclExecute.c:1053
#15 0x48088509 in Tcl_EvalObjEx (interp=0x804f020,
objPtr=0x806a020, 
    flags=131072) at ../tcl/generic/tclBasic.c:4119
#16 0x480e2161 in Tcl_RecordAndEvalObj (interp=0x804f020,
cmdPtr=0x806a020, 
    flags=131072) at ../tcl/generic/tclHistory.c:146
#17 0x481010d1 in Tcl_Main (argc=-1, argv=0xbfbff5fc, 
    appInitProc=0x804890b <Tcl_AppInit>) at
../tcl/generic/tclMain.c:548
#18 0x080488fe in main (argc=1, argv=0xbfbff5f8) at
../tcl/unix/tclAppInit.c:87
#19 0x08048672 in ___start ()

Logged In: YES 
user_id=148712

(from clt)
Also... The script below demonstrates a difference between
unset traces triggered by [namespace delete] compared to
direct unsetting of the variable.
According to the docs the variable being unset should no
longer exist once inside the trace command - and the traces
should have been removed, but this doesn't occur in the
[namespace delete] instance.

 proc Destroy {vtraced vidx op} {
 puts "trace info : [trace info variable $vtraced]"
 puts "info exists: [info exists $vtraced]"
 }
 namespace eval ::ref {set var1 AAA}
 trace add variable ::ref::var1 {unset} [list Destroy]

 namespace delete ::ref

 namespace eval ::other {set var2 BBB}
 trace add variable ::other::var2 {unset} [list Destroy]

 unset ::other::var2


Output on Windows Tcl 8.5a4:
trace info : {unset Destroy}
info exists: 1
trace info :
info exists: 0

Tcl8.4.7 produces the same output. This is likely the same bug.

Logged In: YES 
user_id=148712

A partial fix has been committed to HEAD and 8-4-branch:
insure that a second call to TraceVarProc with
TCL_TRACE_DESTROYED does not lead to a second call to
Tcl_EventuallyFree(). It is still true that that second call
should not happen, so the bug is not completely fixed.

This is possibly due to Bug #1338280.

Logged In: YES 
user_id=80530

FWIW an analogous script
crashes Tcl 8.3.5.  There've
been demons here for a long time.

Logged In: YES 
user_id=148712

With [Bug 1338280] fixed, this should be completely resolved
now.