wish crashing during exit when stdin is closed.

Logged In: YES
user_id=113501

Still reproducible on HEAD.

Logged In: YES
user_id=72656

Works for me on 2004-06-22 head.

Logged In: YES
user_id=113501

Did you test this with threads (and debugging) enabled
because I was able to reproduce this just the other day.

Logged In: YES
user_id=113501

DeleteChannelTable is trying to remove the stdin channel from
the interp even though it was previously closed and it's
channel data freed.

It would seem that stdin was never removed from the interp
channel hash table?

I wonder if there is also a problem with the other standard
channels when using the console?

The other thing I still haven't figured out yet (i'm not an
expert on the Tcl IO subsystem) is whether this is a bug in
the console implementation or some missed corner case in the
Tcl IO subsystem.

Logged In: YES
user_id=113501

CVS HEAD still shows the issue with threads enabled.

Repro:

1. Run wish.
2. In the console, type "close stdin".
3. Leave the console window open and close the main Tk window.

Logged In: YES
user_id=72656

Reproducible in 8.4.12. This is related to [ 1191344 ] std
channel refcount error when wish is child process.

Logged In: YES
user_id=80530

Joe, can you please test whether
today's commit to the Tk HEAD
helped address this at all?

Logged In: YES
user_id=80530

This might, or might not,
be fixed now on the Tk HEAD,
depending on whether the root
cause was in the [console]
machinery, or is still unresolved
in Tcl Bug 1192047. Someone
must test the Tcl/Tk HEAD
on windows to make this
determination.

Logged In: YES
user_id=113501

This is not fixed. Also, the crash can be seen if you close
stdout instead of stdin.

Logged In: YES
user_id=80530

thanks for checking.

Can we get an updated stack trace
to confirm that the remaing
problem is due to Tcl Bug 1192047?

Logged In: YES
user_id=72656

Attached is the crash against today's head (basically the
same, maybe some lines changed):

DeleteChannelTable(void * 0x00d9b1b0, Tcl_Interp *
0x00b85048) line 569 + 3 bytes
DeleteInterpProc(Tcl_Interp * 0x00b85048) line 1042 + 16 bytes
Tcl_EventuallyFree(void * 0x00b85048, void (char *)*
0x10010432 DeleteInterpProc(Tcl_Interp *)) line 312 + 7 bytes
Tcl_DeleteInterp(Tcl_Interp * 0x00b85048) line 932 + 14 bytes
ConsoleDeleteProc(void * 0x00ad98c0) line 878 + 18 bytes
Tcl_DeleteCommandFromToken(Tcl_Interp * 0x00a86000,
Tcl_Command_ * 0x00dd0520) line 2532 + 13 bytes
TclTeardownNamespace(Namespace * 0x00a86fb8) line 1063 + 13
bytes
DeleteInterpProc(Tcl_Interp * 0x00a86000) line 1002 + 12 bytes
Tcl_EventuallyFree(void * 0x00a86000, void (char *)*
0x10010432 DeleteInterpProc(Tcl_Interp *)) line 312 + 7 bytes
Tcl_DeleteInterp(Tcl_Interp * 0x00a86000) line 932 + 14 bytes
Tk_MainEx(int 0xffffffff, char * * 0x00a82e74, int
(Tcl_Interp *)* 0x00401005 _Tcl_AppInit, Tcl_Interp *
0x00a86000) line 309 + 15 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000,
char * 0x0015232b, int 0x0000000a) line 125 + 26 bytes
WinMainCRTStartup() line 330 + 54 bytes

Logged In: YES
user_id=80530

with this "hack" of
a patch, the same failure
can be forced on unix, so
windows-free folks might debug.

Logged In: YES
user_id=72656

Attached is a patch that "fixes" the problem. I need to
make sure that just bumping the refcount of the channels
might not leak them if no console is present.

The change to v4 channels is not important - but I left it
in anyways.

Logged In: YES
user_id=80530

I think that patch is the "correct"
thing, given the mess that's in
the core.

Tcl_GetStdChannel() takes care
to bump the refcount of each
std channel, if it has to establish
one by default. That's the usual
mode for tclsh.

With wish in a mode that establishes
a console, Tk_InitConsoleChannels()
calls Tcl_SetStdChannel() to establish
a different set of standard channels.
Strangely, Tcl_SetStdChannel() does not
do the counterpart of refCount bumping.
It appears that T_SSC callers are
expected to also call Tcl_RegisterChannel()
on the channels they pass in to T_SSC.
That is the pattern followed by the
relevant example in the core, the
Tcl routine Tcl_CreateChannel().

As things are, since Tk_ICC does not bump
the refcounts of its standard channels,
they end up one refcount short and
get freed too early, leading to the
crash. The attached patch corrects
that problem.

It will be interesting to see what
impact this patch has on other
Tcl/Tk std channel/console bugs.
(1192047, 1191344)

Logged In: YES
user_id=80530

fixed in HEAD...