Tcl Source Code

Test script:
~~~
proc trans args {list initialize finalize write}
chan push stdout trans#11 0x00007ffff7b162d0 in Tcl_PopCallFrame (interp=0x6305b0) at /home/aspect/Tcl/Env/src/tcl/generic/tclNamesp.c:404

proc trans args {list}  ;# optional - cleans up output

proc foo {} {puts okay}
trace add execution foo enterstep {puts X; list}
foo
~~~

aborts with:
~~~
file = /home/aspect/Tcl/Env/src/tcl/generic/tclListObj.c, line = 124
incrementing refCount of previously disposed object
~~~

valgrind, memtrace, gdb backtrace attached.

Thanks, it's much better to chase a single goose at a time.
With the proper configure flags I reproduced locally, and with a hardware watchpoint on the (constant) offending "previously disposed object", it appears the last overwrite is a bulk erasure within Tcl_DeleteHashEntry, *not* an individual object-freeing.

So, as you suggest, something very wrong might have happened some time ago, ending up in InitArgsAndLocals passing a bunch of stale pointers to NewList.

Need more digging...

> Or that when compiling with -g, the behavior differs ?

Different compile options make it manifest differently - looks like
memory corruption.  My guess is refcount management, though whether
in trace or transchan machinery or somewhere else I have no idea.
[puts] in both locations seems to be required.

oops.bt is --enable-symbols=yes, the others (and now
oops-tcl-panic.bt) are with --enable-symbols=all.

The stack traces start the same but diverge above TclNRRunCallbacks
at #13/#11 .. maybe that's helpful.

Unless I'm mistaken, the gdb bt ends in a different panic:
"invalid block: 0x7ffff7a0d9af: 2d ff"

Does it mean there is an heisenbug touch to it ?
Or that when compiling with -g, the behavior differs ?