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(a)anest4.anest.ufl.edu
(352) 846-1285