Thanks for spending the time writing a good general debugging guide, David. :)
This forum has really made me appreciate the benefits of one developer spending 15
minutes on an email reply to save another
developer 3 days of fiddling. Priceless.
David Fedor wrote:
> 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/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
