Sorry, but that's a pretty standard C programming risk.
Modern compilers try to warn you when you use uninitialized
variables, but they'd miss this case as well.
Roger
Subject: Uninitialized MemHandle Can Cause Reset Loop
From: "Dr. S.L. Sanders" <s...@sanders-indev.com>
Date: Tue, 25 May 2010 16:33:35 -0700
X-Message-Number: 1
A small 68000 program for my T5 would load and test normally
under the Palm OS Debugger. Closing the debugger would begin a
normal soft reset of the T5, but a fatal exception would occur just
before the "Tungsten" logo would normally appear. A warm reset
would get past this, but tapping the "Home" button would cause
another fatal exception. Thus, a reset loop was in force.
I found (by accident) that the recently-launched list (tap and
hold the silk-screened "Home" button) would appear without causing
the fatal exception, and -- I was lucky enough to find Resco
Explorer in that list!
Resco Explorer allowed me to delete my test program, after which
I could complete a successful soft reset. (Without the accidental
discovery of Resco Explorer in the recently-launched list, I would
have had no recourse other than a hard reset.)
By a process of elimination, I found my programming error that
had been causing the problem:
I had placed the following code in my AppStop() routine,
if(hCel!=NULL) //If global hCel isn't NULL,
MemHandleFree(hCel); // free it.
but hadn't yet gotten around to assigning a value to the global
MemHandle hCel. As soon as I commented-out that code, the reset loop went away.
It's too bad the PalmOS permitted such an apparently-common error
(freeing an uninitialized memory handle) to lead to a situation
that would require a hard reset -- unless you're as lucky as I was.
2010may25(19:42)-sls
Roger Stringer
Marietta Systems, Inc. (www.mariettasystems.com)
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
