Tcl_EventuallyFree called twice - crash; also 'info vars ?pattern?' problem

[neuro...@gmail.com]

Intermittently, usually when shutting down a program, I've had Tclsh
crash saying something like:
Tcl_EventuallyFree called twice for 0x3f6550

I'd never been able to work out what was causing it.. but now I've
found a trivial script that will do this.

namespace eval ::ns {}
trace add variable ::ns::var {unset} [list unset ::ns::var #;]
namespace delete ::ns

Now that's obviously not a very sensible thing to do anyway - but It'd
be nicer if it could generate an error rather than crashing so I
thought I'd better report it. The real case was considerably more
convoluted - involving various write & unset variable traces but
perhaps it too was doing effectively the same silly thing.

On a perhaps related note... This actually turned up whilst I was
trying to debug a problem I'm having with 'info vars ?pattern?'.

Somewhere deep in code that also has various variable unset traces..
the line:
info vars ::pattern::REF::15::arraydata+*
returns
{} ::pattern::REF::15::arraydata+b

I'm at a loss to see how the empty string element turned up in the list
returned by info vars. The docs say that 'only those names matching
pattern are returned'.
arraydata+b isn't actually an array.. and I'm pretty sure a variable
named arraydata+b was just unset from the same namespace. Anyway -
having a devil of a time working out the conditions under which it
happens and how to duplicate it in a simple script.

I could code around the empty string return of course.. but something
just seems wrong about it.. anyone know what might be going on?

I'm using Tcl 8.5a4 (cvs 2005-10-22) on Windows.
The crash bug above also occurs in at least Tcl 8.5a2

JMN

[neuro...@gmail.com]

"and I'm pretty sure a variable
named arraydata+b was just unset from the same namespace"

should read:

"and I'm pretty sure a variable

named arraydata+a was just unset from the same namespace"

[MartinLemburg@UGS]

Hello,

I tried this code ...

| namespace eval ::ns {}
| trace add variable ::ns::var {unset} [list unset ::ns::var; #]
| namespace delete ::ns

... with the tclsh from ActiveTcl 8.4.11.1 and tclkit shell 8.5a2 and
had no crash, no problems!
Trying with the wish from ActiveTcl 8.4.11.1 and tclkit 8.5a2 caused
the same crash - first the message box about calling Tcl_EventuallyFree
twice, than ... good-bye!

So, using tclsh is no problem, but wish is! What's different?

Best regards,

Martin Lemburg

[miguel sofer]

I confirmed the Tcl_EventuallyFree panic both in 8.4 and 8.5, and
opened Bug #1337229 in the tracker
(https://sourceforge.net/tracker/index.php?func=detail&aid=1337229&group_id=10894&atid=110894)

I could not repro the problem with [info vars]: neuronstorm, could you
please monitor the bug ticket and see if the [info vars] problem is
solved when the Tcl_EventuallyFree panic is fixed?

Thanks for the report
Miguel

[neuro...@gmail.com]

see my recent posting in c.l.t for more info on the [info vars
?pattern?] problem.

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