Posted by  George Birbilis on January 25, 2004 at 08:37:22:

it might be a race or deadlock condition, two threads trying to use the same
resources in parallel, maybe locking each other out of the resources

else it could be some very tight (and long running) loop of yours were you
don't yield the CPU at all to other threads or have your thread sleep a bit.
If such a loop does call painting stuff, sometimes an OS can behave very
slowly (on Windows I usually press the "Show Desktop" button on the
quicklaunch toolbar in such cases to hide all windows so that they don't
repaint, then leave it like that for a while, or do Shutdown or Log Off from
the Start menu holding down the CTRL key to force all apps to quit without
being queried by the OS if they wish to do so or given any time to respond
by the OS [this CTRL key is a nice trick btw.])

if you can always reproduce the freezing, but can't break into it with the
debugger, then add logging to your application in such a way that it opens a
file, appends to it, then closes the file (doesn't keep it open all the
time). Have logging calls in all suspicious places. When the freeze happens
force-shutdown the computer (hold the on-off button down for a while, or
press hard-reset button if available, or even pull the plug on desktop
computers or remove the battery on laptops if you can't find another way to
shutdown the computer). Then checkout the log file and see up to where it
has logging. Last command that made it to run was the last in the log. If
you log time as well it will be useful to see how long it takes for each log
point to the next (to see when some loop started to stall).

Then run again with debugger and add breakpoint near the place you found
from the above method and do step-by-step execution, noting stack and other
variable values to see if there's something suspicious

sometimes though when you add logging or do step-by-step, it affects tight
loops and you can't reproduce the problem (makes them less tight cause the
OS when is told to do I/O can get some time to give to other I/O and tasks
it has [since I/O isn't as fast as the CPU it can get some time from it
while waiting for I/O low-level calls to complete])

sometimes a good strategy is to start removing (or commenting out) stuff
from your code till you get to the mimimum program that can still reproduce
the problem (when you remove more stuff it stops having the problem that
is). That can help in finding out what the problematic situation is and
figure out a workarround or a fix for it

cheers,
George

> > Just a wee bit more info: not the whole computer. Just the app. I
> > can't force quit, but the thing is still alive. Although it has
> > visually remain frozen for however long it took me to do the dishes, I
> > came back and attempted to force quit and it played a jump sound which
> > would have happened before it froze. So, I don't know what's going on,
> > but it's something.
>
> Yes, me again. Sorry -- the computer is definitely alive. Before I sent
> that email I tried all sorts of key combos just to see what would
> happen, including holding down the eject key. Three minutes later, the
> cd tray pops out.
>
>
> I've now moved the project over onto my laptop and ran it in
> "developing" mode (doesn't resize the screen and such), and the game
> loop is obviously still going around because it's hitting the
> DoSoundMaintenance function which gives time to QuickTime via
> MoviesTask to keep the sounds playing. Every loop iteration gets longer
> and longer, but nothing is drawn to the screen.
>
> I would love to step through with the debugger if I knew how I could
> use it only where it froze. I'm trying a few different methods but I
> haven't got any to work yet.

Responses:

Post a Response -