Tcl Source Code

If the read method of a stacked channel (temporarily) removes the transformation to send an acknowledgement back to the sender, Tcl crashes with a segfault.

The problem can be reproduced using the attached script.

Probably the chan pop command releases the data structure attached to the transformation handle that is later still needed to process the data returned by the read method.

Either the code invoking the read method should make a copy of the data it will need to finish processing the read action, or removing the transformation inside the read method should fail with an appropriate error message.

Obviously similar problems may happen in other stacked channel methods when they remove the transformation.

Tested on OpenSuSE 11.2, x86_64

Reflected transformation was exposed to scripts in Tcl 8.6.
This does not exist in Tcl 8.5.
Do not confuse with with reflected channel (base channels).

any need for backport here?

allow_comments - 1

Fix committed, after adding test cases, and fixing up 'read' equivalent to 'gets'.

OK, there may be thread issues, but not apparently
specific to the Preserve/Release of handles.

The ReflectedTransform data structure contains
fields (interp, handle, argv) that want to be freed
in the same thread as created them.  If a ReflectedTransform
can take a ride on a Tcl_Channel from one thread to 
another, that's a design flaw, but not a new one created by
this patch.

The patch appears to be a straightforward
conversion to the use of Preserve/Release.
I have not checked for completeness, but the
changes present look sound.

I don't think there are any thread issues.
Tcl_Preserve, etc. operate on global
data structures with mutex protection.
Any thread should have the same ability
as any other to make the Preserve/Release
call on a protected handle.

New patch re-synced to the HEAD and
with corrections to the typecasting warnings
in the Tcl_EventuallyFree() calls.

File Added - 367035: 2921116.patch

Now attached is a patch which seems to fix the problem.

It uses Tcl_Preserve/Release/EventuallyFree to keep the structure around while the channel driver functions are running. This is done only where we have callbacks which could destroy it.

The ReflectClose function is an exception, because when it is run we are in the destruction already. Doing another destruction in its callbacks (drain. flush, finalize) will very likely still crash us. But the preserve/release looks to be very complex, so I punted on it in this patch.

Part of the problem, and also why I am still uneasy about the patch in general is the behaviour in a threaded environment. More specifically, when the channel with the transform is moved into different thread, and then we have preserve/release on the same structure from different threads, and the eventuallyfree may run in the wrong thread ?!

I might be fretting over nothing here, because:

(1) such a self-closing transform as shown in the example will not work at all when the channel it is part of is moved to a different thread, as the handler code will lose access to the channel (handle), and this will stop such an attempt in its tracks before it even reaches the reflection internals at all.

(2) Moving a transform which does not modify/close itself seems to work. At least the iortrans.tf set of tests does pass, no failures, nor crashes.

Reassigning to dgp for review of my code and reasoning.

File Added - 359556: tcl86.2921116.diff-wu.patch

Ok, having read rttest.tcl now I understand what you are doing. Not clear why this is needed, but the mechanics are clear. You have a transform T stacked on a channel C, and T kills itself during processing of 'read' data, and then regenerates itself, i.e. makes a new copy and stacks it.

I attached my Tcl 2009 paper to your other bug about the seg.fault in a reflected channel due to postevent directly called by watch. I recommed to read it and the slides for transforms as well.

Seesm I have to Preserve/Release the rt structure for a larger block ... Oh, and even so the EventuallyFree is missing, bad.

Popping a transformation does indeed kill it; and this indeed implies that all internal state structures for it are cleaned and freed.

File Added - 356445: rttest.tcl