From: <[EMAIL PROTECTED]>
> i´m working on this application that was tested originally on
> Tungsten C and Sony Clie. In both was working fine.
> But now our customer will install like 100 Zires 72 with this
> application. The problem is that when trying to exit the
> application there is a fatal exception.
> I've tried to debug with CW, but I can not reproduce the fault.
> The same Zire works perfect while debugging.
>
I have no idea what the problem is, but found that an excellent
tool for tracking down this sort of problem was a simple logging
module that wrote text to a PDB. Although this isn't as good as
source-level debugging it has the advantage of running on the
actual device and so has more chance of capturing the sequence
of events that lead to the crash.
I had a fairly complex module that tracked many resource issues
for tracking problems with serial-connected hardware, but for
this sort of thing all you really need is a couple of functions that
- create a database using a timestamp for the name (so that
new runs don't over-write previous debug data and to help
keep them organised when you've hotsynced them back to your
PC).
- a function to write a string to the pdb (it can be useful to format
the string as a string of comma separated values that starts
with an incrementing index and then a tickcount - this lets
you easily import it into a spreadsheet to filter out the crap).
- then call that function at the top of important functions and
anywhere you want to dump a data value or signal that
something happened.
Hotsync the device, grab the pdb from the backup directory
and use one of the pdb 2 cvs converters to convert to a
text file (one of the reasons you want each record to just be a
formatted string) and voila - you can see the point the code
crashed. It'll take a couple of round trips to start isolating
the problem but with any luck it will get you to the point where
you can actually get some info about the crash where-as at
the moment you're probably just trying to guess what might
be happening.
It sounds like a lot of work just to trace the execution flow
but trust me that this is invaluable (and reusable) whenever
you've got a problem that only occurs on the device (or that
other support nightmare: a problem that only occurs on one
client's device). One of these days I'll get around to putting
my debug module up on-line, but I just don't have the time
to debug and document it.
Chris Tutty
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
