[Tcl-bugs] [ tcl-Bugs-1322866 ] TclFinalizeIOSubsystem closes zero descriptor

[SourceForge.net <no...@so...>]

Bugs item #1322866, was opened at 2005-10-10 16:23
Message generated for change (Comment added) made by mteira
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1322866&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 25. Channel System
Group: obsolete: 8.4.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Manuel Teira Paz (mteira)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: TclFinalizeIOSubsystem closes zero descriptor

Initial Comment:
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.



----------------------------------------------------------------------

>Comment By: Manuel Teira Paz (mteira)
Date: 2005-10-11 09:19

Message:
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?

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2005-10-10 23:27

Message:
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.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2005-10-10 20:34

Message:
Logged In: YES 
user_id=80530

see also 1192047


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1322866&group_id=10894