Curiosity got the better of me today, and I did some VM building.
First, I made a simple manual switch of printAllStacks() for printCallStack() in the win32 pref menu, then built using the latest source tree from Source Forge. I put the new VM on the offending machine, waited for the lockup, and then printed the dump. It produced an output with multiple processes. A few things stood out. First, the dump contains a fair number of "extra" blank lines; more on that later. One false alarm (I think) was some #doesNotUnderstand: activity in what appears to be the finalization and timer threads. It looks suspiciously like the output from the Process Browser :) The morphic main loop was waiting inside of #interCyclePause: (seems reasonable, except that it's happening for far too long) rather than (as I expected) stuck on a critical section held by one of my other threads.
Perhaps most interesting is that the other thread did not appear in the dump. There is a way that it might have exited, but I would expect a logged error that I'm not seeing.
Running the offending app and **not** waiting for the deadlock gives a dump that similarly shows multiple processes, some extra blank lines, includes the threads that I expected to see, but does not include the morphic main loop.
Wondering whether the stack printing might be exiting early, I tweaked it with some leading/trailing #print:, translated, and rebuilt. The blank lines still appear, but there is no evidence that call stacks were started and not finished. Each process has a start/stop line, and there are no orphaned start lines.
Is there a state that's not represented in the dump? Any other ideas?
Some suggestions:
(1) an obvious header line helps when trying to sort out dumps made at different times (2) it might be helpful to include each process' priority in the dump
Finally, re MinGW installation, I think it's possible to edit the path (and other ev's) in win2k using control panel/system/advanced/ev's and edit the variable of interest. Include no extra spaces in the path though, or it won't work??? Anyway, it appeared to work w/o a reboot.
Bill
Wilhelm K. Schwab, Ph.D. bills@anest4.anest.ufl.edu (352) 846-1285
squeak-dev@lists.squeakfoundation.org