[Tcl-bugs] [ tktoolkit-Bugs-1191344 ] std channel refcount error when wish is child process

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

Bugs item #1191344, was opened at 2005-04-27 18:03
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1191344&group_id=12997

Category: 54. [console]
Group: development: 8.5a3
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Porter (dgp)
Assigned to: Don Porter (dgp)
Summary: std channel refcount error when wish is child process

Initial Comment:

Attempt to distill the useful bits
of information from report 1186042
into a new report here.

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

>Comment By: Don Porter (dgp)
Date: 2005-04-28 16:58

Message:
Logged In: YES 
user_id=80530


Tk_Init does a [tcl_findLibrary],
which triggers the auto-loader,
and [auto_load_index] calls
[open] on each tclIndex file.
A side effect of [open] is to
register stdin, stdout, stderr
in the interp, bumping the
refcount of each one.


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

Comment By: Don Porter (dgp)
Date: 2005-04-28 16:51

Message:
Logged In: YES 
user_id=80530


Tcl_Init is called, but that does
nothing with std channels.



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

Comment By: Don Porter (dgp)
Date: 2005-04-28 16:13

Message:
Logged In: YES 
user_id=80530

So the logic of 
ShouldUseConsoleChannel(TCL_STDIN)
is reproduced in Tk_MainEx.  LIkely
candidate for a good refactoring.

Under the assumptions of the bug report,
I think we can conclude that tsdPtr->tty
will be 0, and so will tcl_interactive.

Then on to the Tcl_AppInit call...

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

Comment By: Don Porter (dgp)
Date: 2005-04-28 15:59

Message:
Logged In: YES 
user_id=80530

Then back to Tk_MainEx
and through lots of command line
parsing code that's not relevant.
Skip down to line 206, and note
the comment "This probably isn't
the right way to do it. "  hmmmm...



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

Comment By: Don Porter (dgp)
Date: 2005-04-28 15:46

Message:
Logged In: YES 
user_id=80530

Moving on then, Tcl_FindExecutable
returns, then Tk_InitConsoleChannels
-> ShouldUseConsoleChannel
-> Tcl_GetStdChannel.

Presumably, this creates all 3 standard
channels, bumps all refCounts to 1,
and SUCC returns 0 all three times?



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

Comment By: Don Porter (dgp)
Date: 2005-04-28 15:40

Message:
Logged In: YES 
user_id=80530


Oops, there I go with the false
info again.

The auto-setting of std channels
in Tcl_CreateChannel only happens
for each std channel after it has
been "initialized".  So this mechanism
can refill a lost std channel, but won't
establish an initial one.





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

Comment By: Don Porter (dgp)
Date: 2005-04-28 14:25

Message:
Logged In: YES 
user_id=80530


Program starts in WinMain,
where consoleRequired is
set to TRUE.

Then, Tk_MainEx calls
Tcl_FindExecutable.  The
system encoding gets
initialized, which involves
reading from a *.enc file.
Opening that file channel
involves a call to Tcl_CreateChannel.
At the end of Tcl_CreateChannel,
the file channel to the encoding
file becomes "stdin".

ok, that's... weird.

All the cp* encodings that can be
[encoding system] values on
Windows are not escape encodings,
so there's only the one file channel
to worry about.

After the encoding data is read, 
Tcl_Close is called.
CheckForStdChannelIsBeingClosed
sees a refCount of 1, and resets
"stdin" to be undefined.

So, I think that's weird, but unrelated
to the symptoms reported.

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

Comment By: Don Porter (dgp)
Date: 2005-04-27 18:14

Message:
Logged In: YES 
user_id=80530


When line 201 of revision 1.22
of tkConsole.c is reached, a
prior call to Tcl_GetStdChannel()
has returned a non-NULL Tcl_Channel,
and an internal refcount in the Tcl_Channel
has been incremented.

Somehow this increment is one more
than the finalization code of Tcl expects,
and Tcl fails to close the system side
of the channel(s) during app shutdown.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1191344&group_id=12997