Tcl Source Code

The following code causes the Tcl interpreter to crash. Note the code is buggy (recursively enters the blocking proc via chan configure. But should not cause an interpreter crash.

namespace eval demo {}
proc demo::initialize {chan mode} {
    return {initialize finalize watch blocking read write configure cget cgetall}
}

proc demo::finalize {chan} {
}

proc demo::blocking {chan mode} {
    chan configure $chan -blocking $mode
    return
}


namespace eval demo {
    namespace export initialize finalize blocking 
    namespace ensemble create
}

set ch [chan create {read write} demo]
chan configure $ch -blocking 0

-> crash

fix merged to trunk.

Fix committed to 8.5 branch.

Additional cleanup and improvements pending.

> This is presumably so that the cost of allocating
> a new eval array doesn't have to be paid each time.

I am very sure that this is what is was thinking at the time.

> can only be InvokeTclMethod() call operating on each
> reflected channel at a time.

Yes. Also something I was definitely _not_ seeing when writing the code.

So, possible solutions ...

(1) Dynamically (de)allocate the damn array in each call of InvokeTclMethod()
(2) Flatly forbid the recursive entry of InvokeTclMethod().

In terms of implementation both possibilities seem to be equivalent in difficulty, i.e. while not trivial, at least easy.

In light of other data structures needing to be preserved for such calls, as demonstrated by related bug reports I currently trend towards preferring (2).

This one is pretty ugly.

The problem arises because the reflected
channel builds the command to be evaluated
in an array within the reflected channel
data structure, rcPtr->argv .  This is presumably
so that the cost of allocating a new eval array
doesn't have to be paid each time.

The problem is if there is one argv array per
reflected channel, then there can only be one
InvokeTclMethod() call operating on each
reflected channel at a time.  As soon as you 
try to do two concurrently -- such as when 
one nests in the other -- they will stomp on
each other's argument words, and crashing is
about the nicest thing to expect.

Most likely some data structure not getting properly preserved and/or locked against bad re-entrance.

Likely also in the 8.6 branch, and novem

Confirmed the segfault.

Also crashes in 8.5.15 and 8.5.0, so
this is not a recent regression.

Passing on to the refchan maintainer for
a deeper look.