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
* After all the exit handlers are run, it winds up
* 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
* 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)