Daniel Seifert wrote:
Hi,
Am Freitag, den 17.03.2006, 10:30 +0530 schrieb sanjib mohanty:
Hai all
Thanks for replying
As daneil suggest the solution, I checked all the MemHandleLock and
corresponding Unlocks, DmReleaseRecord and DmGetRecord, all were
matched properly.
You should be matching more than just those. Something like:
MemHandleNew with MemHandleFree
MemHandleLock with MemHandleUnlock
MemPtrNew with MemPtrFree
DmGetRecord with DmReleaseRecord
DmNewRecord with DmReleaseRecord
etc...
There are variations on these; for instance you could use a MemPtrUnlock
after a MemHandleLock, unlocking the pointer instead of the handle, but
I prefer to match the lock and unlock on the handle.
There are any number of ways that you can mess up the memory. For
instance, you can write to memory that doesn't belong to your app, in
ways that the emulator or simulator won't catch. In such cases you
might experience a crash after you exit your app and are accessing some
other application. These can be very difficult to troubleshoot, and you
will need to do extensive testing to locate a pattern, then disable
parts of your code to try to make the error disappear/happen reliably.
Then you will know that you have found the error, and you will have a
way to test your fix.
My suggestion would be to simplify your app, bypassing large parts of
your code, until you can get it to run reliably with no crashes. Then
enable sections at a time until the crashes start to reappear. Fix the
problem in that function, and look for any other instances where you
handle memory the same way, and fix those too. Then keep enabling more
parts until the whole thing works properly. Yes, this can be a painful,
time-consuming process.
--
Bob
www.rmobile.ca
--------------
Mobile software for handheld computers and smartphones
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
