I debug "undebuggable" situations like this by a few different methods.
("Undebuggable" can mean anything from that you can't connect a debugger
since you don't have a USB->serial dongle handy, or you're using the serial
port for something else, or it affects memory, etc.)
- Call FrmAlert to help you trace through, and have it show values of
variables etc. The problem with this is that it can affect timing and/or
the data on the stack, which can change the effects of uninitialized
variables, which are too often a cause for problems of your nature. (No,
not you as a person...)
- Do pseudo-tracing by drawing things to the screen. Just slam text up in
the title bar, or draw a "1" on the screen when you get to location 1, and
then a "2" a little further down, etc. So when it hangs, you see where it
got to. Then you do a binary search to find the problem area. Ditto on
the problems of possibly changing the system characteristics.
- Beep at various locations. Again, ditto for possibly changing the system
characteristics, but it might work where drawing doesn't. (Particularly if
you're debugging a drawing problem.) SndPlaySystemSound takes a parameter;
use different ones at different spots.
- Write an app that sets byte 0x101 to 0x81, on current (physical, not
emulated) devices, and run it before launching your app. That's a
debugging trick which will cause the HotSync interrupt button to cause the
device to connect out the serial port to PalmDebugger, immediately. So you
reset the device, run your app that tweaks this global, and then run your
app, and hit the hotSync button and you'll connect to PalmDebugger, with
zero changes to available memory or timing up until the point you hit the
button. If you're in an infinite loop, this is a way to find out where you
are, since a stack trace will work. And if you're good with assembler, you
can do all your debugging right there.
- Perturb the stack and heaps, to change the values of uninitialized data.
Do that by allocating some blocks of memory and leave them there, and/or
filling them with zeroes or other values, like 0xffff or 0x1234 or
0xDEADBEEF or your lucky number.
- If you're not using current versions of the Palm OS Emulator, do. Log
what traps are called. Insert a call to a benign trap to help you make
sense of where you are, since the logs can have a ton of data that is hard
to sift through. Try calling the HostControl APIs to dump info out, if you
can do this and not change memory enough to mask the problem.
Hope one of these does the trick. Good luck.
-David Fedor
Palm Developer Support
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
