I forgot to finish one thought. What storage and dynamic heap allocations have in common is they both result in a pointer. You must store this pointer someplace. Where do you store it? Does the place you store it go away between the time you allocate memory and the time you free memory?
On Tue, Mar 10, 2009 at 12:12 PM, Jeff Loucks <[email protected]> wrote: > What Dmitry is so eloquently saying is that MemPtrNew() and > MemHandleNew() allocates from dynamic heap, which is volatile RAM. The NAND > is a type of flash reprogrammable ROM. The flash ROM is where your databases > records and resources end up, after spending some time in an intermediate > cache in RAM. It is supposed to act like the old storage heap of earlier > PalmOS versions, which was a write protected battery backed portion of RAM. > FtrPtrNew() allocates from the storage heap, just never gets written to > flash ROM. > > So, to sum up, if freeing memory allocated from both dynamic and storage > heaps fails, then it is probably something they both have in common. We've > suggested several things; 1) you are writing outside the bounds of your > allocated memory, messing up the allocation pointers, leading to failures > when freeing, 2) you are storing the pointer to allocated memory in an > unreliable place (globals or stack), and not using the correct pointer when > freeing, and 3) you are freeing memory more than once. > > I pointed out that option 1) should not be possible with FtrPtrNew(), since > you must use DmWrite() to write to it and DmWrite() is supposed to guard > against overwrites. Option 2) is possible, but your code example does not > tell me where your globals pointer (GLB?) is stored, so I cannot determine > the persistence of GLB. Option 3) is possible. There are ways to protect > against freeing problems. Otherwise, walk through the code, executing in > your head, and follow what is happening. > > There is a fourth option (probably others). Does your code allocate memory > that persists from one application instance to another? You say you cannot > use globals. Where do you store GLB? If your memory must persist from one > app instance to another, then you will need to change the owner of the > memory from the app to the system (MemPtrSetOwner(memptr,0)), so that the > memory is not cleanup up (freed) out from under you when the current app > instance terminates. > > Of course, it could be all of the above, but Ockham would disagree :) > > > On Tue, Mar 10, 2009 at 11:12 AM, Dmitry Grinberg <[email protected]>wrote: > >> GRANULARITY OF THE NAND? >> >> >> >> FOR THE LAST TIME: >> >> YOU ARE not ALLOCATING MEMORY IN THE NAND FLASH! >> YOU ARE NOT ALLOCATING MEMORY IN THE NAND FLASH! >> YOU ARE NOT ALLOCATION MEMORY IN THE NAND FLASH! >> >> >> am i getting through? >> >> >> >> ---- >> Best Regards, >> Dmitry Grinberg >> (847) 226 9295 >> >> >> >> -- [Jeff Loucks, Gig Harbor, WA, USA] -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
