#1295 SSH and threaded Tcl: file events get missed

obsolete: 8.2

OriginalBugID: 2661 Bug
Version: 8.2
SubmitDate: '1999-08-31'
LastModified: '1999-12-17'
Severity: MED
Status: UnAssn
Submitter: techsupp
ChangedBy: hobbs
OS: Solaris
OSVersion: 2.6
Machine: Other
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Michael Santos

Channel event handlers are never invoked for a TCP server socket even
though Tcl_DoOneEvent is called to check for all events when the server
is running on a remote machine via ssh. This is a modification of my
previous bug report program. When linked with Tcl compiled with thread
support, the ConnectPort function will never be invoked in response to a
connection, even though the process connecting to the included program
sees that the connection is established. I guess an accept in done on
the underlying socket, but the handler associated with it is never run.
When linked against Tcl without thread support, everything works
correctly. Similarly, if the server is run on a remote machine via rsh
instead of ssh, everything works correctly. Perhaps this is really a
bug in ssh; I don't know.

To test, compile the program below: call it server. ssh into another
machine and run the server in the supplied shell. On the local machine,
fire up Tcl and connect to the server via "socket <remote machine>
50099". ConnectPort will almost always not be invoked. Occassionally,
I have seen it invoked many (20-30) calls to Tcl_DoOneEvent later.

The sample C file follows. The executable takes a single argument that
controls how quickly Tcl checks for events.

#include <stdio.h>
#include <tcl.h>

Tcl_Interp *gInterp;

ReadData(ClientData clientData, int mask) {
char buf[256];
fprintf(stderr, "ReadData() called\n");
while (Tcl_Read((Tcl_Channel)clientData, buf, 255) > 0) ;
Tcl_Close(gInterp, (Tcl_Channel)clientData);

ConnectPort(ClientData clientData, Tcl_Channel new_socket,
char *hostName, int port) {
fprintf(stderr, "ConnectPort() called with hostname %s, port %d\n",
hostName, port);
if (Tcl_SetChannelOption(gInterp, new_socket,
"-buffering", "none") != TCL_OK) {
fprintf(stderr, "Error setting buffering option on TCL socket.\n");
if (Tcl_SetChannelOption(gInterp, new_socket,
"-translation", "binary") != TCL_OK) {
fprintf(stderr, "Error setting translation option on TCL "
if (Tcl_SetChannelOption(gInterp, new_socket,
"-blocking", "FALSE") != TCL_OK) {
fprintf(stderr, "Error setting blocking option on TCL socket.\n");

Tcl_CreateChannelHandler(new_socket, TCL_READABLE, ReadData,

StartServer(ClientData clientData) {
Tcl_Channel socket;
fprintf(stderr, "StartServer() called.\n");
socket =
Tcl_OpenTcpServer(gInterp, 50099, NULL,
ConnectPort, (ClientData)NULL);
if (!socket) {

Tcl_AppInit(Tcl_Interp *interp) {
gInterp = interp;
if (Tcl_Init(interp) != TCL_OK) {
fprintf(stderr, "Tcl failed to initialize.\n");


return TCL_OK;

main(int argc, char *argv[]) {
int i;

gInterp = Tcl_CreateInterp();

while (1) {
for (i = 0; i < atoi(argv[1]); i++) ;
fprintf(stderr, "Checking for events.\n");
while (Tcl_DoOneEvent(TCL_DONT_WAIT)) {
/* Empty while loop */
return 0;

When a server socket is opened on the other end of an ssh connection,
file events are improperly recognized -- usually ignored, but sometime
greatly deferred. It seems to be related to ssh's port forwarding
feature, as connecting with "ssh -x", which disables the X11 forwarding,
leads to correct behavior.

I would expect that the connection would work regardless of whether ssh
is forwarding X11 traffic and whether or not Tcl is compiled with
threads support. For some reason, only the threaded version seems to be
affected by ssh's X11 port forwarding.


  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-03-22
    • status: open --> closed-duplicate
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2002-03-22

    Logged In: YES

    This appears to be a dup of 219301


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks