On 8/7/02 3:18 PM, "Dave Lippincott" <[EMAIL PROTECTED]> wrote:

> I can't tell you where you code is crashing from just the error code without
> being in on the project.  I can say I'm 99.99% sure its something, somewhere
> in your code.  There are tons of things your code can do that will later
> blow up an internal OS function.
> Some include (but not limited to):
> -Forgetting to add 1 for NULL when allocating memory for string.
> -Free memory for a control after the OS already has.
> -Over bound a string (which may corrupt a pointer or other data)
> -Assign a handle to a field when the handle variable is out of scope and
> later free the handle or remove the field.
> -Copying more text into static text field than the field was originally
> designed to hold.
> -Modifying a dialog's title, adding more characters than originally
> allocated.
> -Messing up on your pointer arithmetic (when directly playing with pointers)
> 
> What I've done in similar situations is post entries and exits from my
> suspect functions to a log.  Pose has a nice feature where you can post
> strings to an external log for review.  Find out the last function in your
> app to get called, narrow down the list of suspects.  You will find the bug.

My mistake for assuming the debug roms would catch that much for me :-)

Thank you for all your help.  Time for me to start re-enabling all
my HostTraceOutputTLs :-)


> 
> ----- Original Message -----
> From: "Lally Singh" <[EMAIL PROTECTED]>
> To: "Palm Developer Forum" <[EMAIL PROTECTED]>
> Sent: Wednesday, August 07, 2002 12:58 PM
> Subject: Re: handle at 0x8000187C causes PrvPtrFree to access 0x0000005D,
> address bus error
> 
> 
>>> Yeah, this is what the emulator told me.  Problem is that the access
>> is from PrvPtrFree, a PalmOS internal function.  I'm passing in a value
>> like 0x8000187C into MemHandleFree, and it calls PrvPtrFree, which then
>> crashes my app.
>> 
>> The value I pass into MemHandleFree looks like a valid handle address,
>> and the variable I'm storing the handle address in only gets its
>> value from a MemHandleNew.  The problem only shows up after
>> several thousand (~12,000) gremlin events.  Is there some way to
>> invalidate a handle other than deleting it?  Or does this look like
>> an attempt to delete a handle more than once?  I'm a little lost as
>> PalmOS typically complains about double-freeing a handle.
>> 
>>> 
> 
> 
> 
> 



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

Reply via email to