#3259 TclFinalizeIOSubsystem closes zero descriptor

[Manuel Teira Paz]

Embedded interpreter into an application that is not
using zero descriptor for stdin, gets this descriptor
closed (a AF_INET socket in this case) when
Tcl_FinalizeThread is called:

ff3705b0 close (0, 13b320, 4, 2, 0, ff331be0) + c0
fed91eac TcpCloseProc (150f10, 0, fed91e9c, ff3dc790,
0, 1) + 10
fed5fdfc CloseChannel (0, 16cff0, 13b320, 7efefeff, 6e,
6e) + e8
fed5fd00 FlushChannel (0, 16cff0, 0, 0, 67, 67) + 298
fed60170 Tcl_Close (0, 16cff0, feda0af0, feda0b00, 0,
2) + 148
fed5e9a0 TclFinalizeIOSubsystem (146330, fed68928, 68,
39924, aebd8, 0) + a8
fed4d3d4 Tcl_FinalizeThread (fd40f3c0, b0e90, aeaf4,
fd40f3d0, 184, af488) + 8c

This file descriptor is not related with the embedded
tcl subsystem, neither used or referenced from tcl code.

This is happening on a Solaris 8 platform using sparc
binaries.

[Don Porter]

Logged In: YES
user_id=80530

see also 1192047

[Donal K. Fellows]

Logged In: YES
user_id=79902

Thinking about this (not very deeply though) it seems to me
that FD 0 (and 1 and 2) should only be magical (outside of
the [exec] guts) if it is open when we init the IO
subsystem. Otherwise, the special behaviour attached to
stdin (stdout, stderr) should simply vanish. OK, that'll
make a number of things unhappy, but it'll be up to script
authors to deal with that (and it should at least be better
than a crash!)

Alternative is to hack around closed std channels by opening
the platform's null device in their place. Not as elegant
though.

[Manuel Teira Paz]

Logged In: YES
user_id=308238

I don't know what is the best solution. Anyway, it seems to
me that there are two different problems.
One of them is the interpreter closing file descriptors not
opened by itself. That's what is happening here.
The other one is if the interpreter is able to tell if a
file descriptor is actually stdin/stdout/stderr. File
descriptor 1 can be a regular file not related with stdout
when my process is a daemon, and could also be stdout in
this situation if I exec'ed it using redirection. Are these
cases distinguised?

[Don Porter]

Logged In: YES
user_id=80530

"interpreter closing file
descriptors not opened by
itself" is a (underdocumented?)
feature of Tcl_MakeFileChannel().
That's a very old interface
predating the existence of a
Tcl_Finalize() distinct and
separate from Tcl_Exit(), IIRC.
There are existing programs
that rely on T_MFC acting
this way.

It's not so clear that when
Tcl creates default standard
channels that it ought to be
calling T_MFC to do it, given
this feature. Now that existence
of Tcl_Finalize() suggests Tcl
supports finalizing in an app
that will continue to run, it
doesn't seem to be a good thing
that Tcl forces closed the file
descriptors corresponding to its
standard channels.

And in this particular report,
there's the additional wrinkle
that in this case file descriptor
0 isn't even the right thing to
attach to the "stdin" channel.

Since this report is about an
"embedded interpreter" I assume
the app in question is a C program,
and the workaround ought to be to
include whatever Tcl_SetStdChannel()
calls are required to force Tcl to
use some harmless alternatives for
its std* channels, and not the
0, 1, 2 file descriptors being used
in other ways by the program.

[Don Porter]

Logged In: YES
user_id=80530

Putting this in the
"Won't Fix" file. Correct
way to deal with this issue
is to use Tcl_SetStdChannel()
to give Tcl some other channels
to do its stdfoo businees with
when it ought to keep its hands
off of file descriptors 0, 1, and 2.