Tcl Source Code

test trace-32.1 {nystery memory corruption} knownBug {
    proc foo {} {}
    trace add command foo delete foo
    trace add execution foo enter foo
    set result [trace info command foo]
    rename foo {}
    set result
} [list [list delete foo]]


This test causes a segfault.

apparently related to the fact that
the deletion trace tries to call the
traced command, but still needs
further tracking down.  It's nasty
memory corruption somewhere.

Logged In: YES 
user_id=80530

fixed for 8.4.5+

Logged In: YES 
user_id=80530

Thanks.  I have good confidence there
will be no trouble untracing the trace
at that point, because the ActiveTrace
trickery is used throughout the trace
system just to enable the untracing at
any time.

Logged In: YES 
user_id=32170

As far as I can tell, this looks ok, but I haven't fully
investigated the implications of calling Tcl_UntraceCommand
at that point.

p.s. thanks for looking into all these 'trace' issues, and
sorry I haven't been more forthcoming with help/advice.

File Added - 63233: 811483-HEAD.patch

Logged In: YES 
user_id=80530

Here's the corresponding patch
for the HEAD.

File Added - 63227: 811483.patch

Logged In: YES 
user_id=80530


This patch stops the accessing
of freed memory by test
trace-32.1, and also corrects
some coding errors found
along the way.

Assigning to TIP 62 implementor
for a chance to comment.

Logged In: YES 
user_id=80530


at least some of the problem
appear due to an error in
refcounting of the
TraceCommandInfo struct
in TraceCommandProc().
There the refCount is
decremented without actually
removing the reference, and
the inconsistency leads to trouble.

There are probably good lessons
on how to get this right in the
variable tracing code.