Since [c085b9090c8ae821] (New Windows console driver. Fixes [21280817d1] thread proliferation and [44bbccdd8c] fconfigure std{out,err}.), in a freshly built Tcl from core-8-branch, when running "package require Tk" I get a MSVC Runtime Library debug check triggering: "Run-Time Check Failure #3: The variable 'needEvent' is being used without being initialized."

I believe this comes from a missing initialization in ConsoleCheckProc in tclWinConsole.c:838 but there must be something more about this because when I add this initialization:

int needEvent = 0;

then the console runs (run-time check error is gone) but the continuation lines are broken in the console: it is no longer possible to enter more characters. Example: just enter: "proc a {} {", hit the enter key and it's stuck.

Comfirm [189e348c49] works for me. Thanks!

As an aside, I'm a little surprised the compiler did not warn of uninitialized use. I thought they would.

Found the issue and fixed it. Testing now.

@sebres - just initializing needEvent does not suffice.

@sebres - regarding lock deadlocks, pretty much all my code (here, iocp, isapi) uses lock hierarchies to prevent deadlocks. See comments in the code (search for hierarchy)

/Ashok

Fixed in [fce5cfe1c7e872fe]...

Just I must admit, I saw something that may be potentially dangerous:

ConsoleCheckProc locks two mutexes in a nested way. This is theoretically a candidate for a deadlock in certain circumstances.
Ashok, can we be sure there are no constellations where it could happen?
I mean TH-A locks gConsoleLock and want to lock handleInfoPtr->lock, in the same time TH-B that still hold the lock on handleInfoPtr->lock attempting to lock gConsoleLock for some reason, what would cause a freezing. We can have one actor more that (especially by read/write locks) make some exclusive (W) lock for some of them, so finally it could lead to hardly reproducible heisenbug.

Ashok, may I assign to you since you touched this very recently? Thanks!