#2994 threaded exit can reinit PipeInit on exit and crash

[Jeffrey Hobbs]

There is an issue with finalization of the threaded
Windows build that can appear in winDde.test and
occasionally winPipe.test. Kevin narrowed it down to
this series of events:

* Tcl_Finalize is called from Tcl_Exit and runs all the
exit handlers.

* After all the exit handlers are run, it winds up
calling Tcl_FinalizeThread.

* From there we get into Tcl_FinalizeIOSubsystem, and
thence to Tcl_Close

* We have an open pipe at this point, so we get into
PipeClose2Proc from tclWinPipe.c.

* This calls Tcl_CleanupChildren -> Tcl_WaitPid

* and Tcl_WaitPid finds that the pipe subsystem isn't
initialized - because its exit handler has already run,
so calls PipeInit, re-establishing the exit handler.

* Now we shut down the zippy memory allocator - with
the exit handler still on the list.

* The last-ditch Tcl_Finalize in DLL_PROCESS_DETACH
finds the exit handler and runs it - and then frees the
memory.

* Which is now in use as a CRITICAL_SECTION down in the
C runtime... boom.

* I believe that it's a threaded problem only, and the
exit handler is being created in Windows-specific code.

* I don't know if there's similar code in Unix.

This is perhaps related to 990457 (this is unix
specific, but about threaded exit behavior)

[Joe Mistachkin]

Logged In: YES
user_id=113501

Argle. I bet this is causing a number of issues I've been
seeing on Win32.

Unfortunately, I do not know enough about how the IO
subsystem is supposed to work.

This bug is only loosely related to bug 990457, if at all.
This bug is almost certainly related to bug 912571.

[Don Porter]

Logged In: YES
user_id=80530

Have the finalization fixes since
the last comment resolved this one?

[Kevin B KENNY]

Logged In: YES
user_id=99768

I would presume that it's fixed by my commits of 2005-06-22.
The controversial panic in Tcl_Finalize to guard against
creating
an exit handler after exit handlers have already run should
protect us against having this problem recur.