From: "Dr. Vesselin Bontchev" <[EMAIL PROTECTED]>
> > It doesnt lock up on the simulator, but it does on the device.
> 
> This is an unpleasant one... It is not supposed to happen. 
>
In practice it will happen for all sorts of things.  I've regularly had 
code work fine on the simulator and lock up the device (generally
intermittently).  It often seems to be related to the hardware
altering the timing of sequences or locking resources differently 
(the most recent I had was an API call that was sometimes causing 
a reset during startup on a T3, but was theoretically sound and 
worked fine in testing. I suspect that that was related to the app 
attempting to call the API early in the startup sequence while the 
OS still had the associated resources locked, since when I altered
the logic to delay the API call the problem went away).

What I found useful over time was to develop a set of logging
functions that wrote to a database.  This database could then be 
picked up from the backup folder and analysed.  It's slower than
debugging, but then I used to spend a lot of time with external
devices connected to the serial port and that pretty much trashes 
your chances of device-based debugging.  It's also impossible to
trace timing-dependent problems by stepping your code. And
finally, you can send a log-enabled copy of your app to that one
person who can reproduce that last intermittent crash and have
them return the log pdb to you.  Try doing *that* over a serial 
port  :-)

The logging functions don't have to be complicated, just open a
database and just write data strings to it.  It's useful to write comma-
-separated strings that start with an incrementing value and a log 
entry type because you can then dump the data out to a text file and 
import into a spreadsheet or database for analysis.  This is useful 
when you've got twenty thousand lines of debug log and you want 
to pick out one type of log entry.  Including the current tick count is 
also sometimes useful.

I keep meaning to package my log routines as a resource for
developers, but it's only an hour or so's work to write your
own so...

Chris Tutty


-- 
For information on using the Palm Developer Forums, or to unsubscribe, please 
see http://www.palmos.com/dev/support/forums/

Reply via email to