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 > > > > On Tue, Mar 10, 2009 at 8:59 AM, Darren <[email protected]> wrote: > > Hello and thanks for responses, > > > > at the moment the function that inits the global list items and variables > is storing around 50 * 20 strings, the chunk is allocated at application > startup and is set at 8kb (8192) as there was mention somewhere of > granularity of the nand. > > > > therefore is not writing outside the malloc. > > > > When the pointer being used to store either the locked MemHandle or the > MemPtr is displayed as a 4 byte numeral (in other words the address > location) after being declared and also just before the items are written to > the chunk, they are the same. > > > > > > Still have not found a solution. The desk accessory cannot use globals, > as no desk accessories can, although there are a few methods around this, > Ftr memory, prefs, a typedefed global struct, etc. > > > > something like so : > > in included header > > > > typedef struct psuedo_globals { > > // form > > Int16 X; > > Int16 Y; > > Int16 W; > > Int16 H; > > > > // pen detection > > RectangleType P[MaxPenDetectAreas]; > > > > // DeskHandler > > Coord x_DIFF; // form move coords > > Coord y_DIFF; > > Coord x_STRT; > > Coord y_STRT; > > Coord x_SAV; > > Coord y_SAV; > > > > // etc., etc... > > > > }psuedo_globals; > > > > > > > > then in the main.c for the desk accessory would be something like: > > > > > > // •••••••••••• •••••••••••• •••••••••••• > > //start > > Int8 start(void){Deskmain(); return 0x00; > > > > -- > For information on using the ACCESS Developer Forums, or to unsubscribe, > please see http://www.access-company.com/developers/forums/ > -- [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/
