To see a good discussion on this kind of "sentinel markers", check out "Writing Solid Code" by Steve Maguire, particularly the "Fortifying Your Subsystems" chapter. It's an old book, but still a really good one. Here's the obligatory Amazon link: http://www.amazon.com/exec/obidos/ASIN/1556155514/104-0032562-1527954
-Jon ------------------------------------------- Jonathan Hays Palm OS Certified Developer http://hazelware.luggle.com ------------------------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Chris Tutty Sent: Sunday, February 27, 2005 1:57 PM To: Palm Developer Forum Subject: Re: Invalid chunk ptr after exiting app From: "Richard Coutts" <[EMAIL PROTECTED]> > I've been reading through the architives and seeing that this is likely > because I'm overwriting a chunk header, or something to that effect. My > apps pretty big, so I'm having a tough time tracking down where this might > be happening. When I make changes to the code, it sometimes goes away, but > it appears as though this is only because the bug is effecting less critical > parts of memory. > > I could use some guidance as to how to track this down. My knowledge of > debugging is pretty much limited to reviewing whatever line of my code the > simulators flag or looking at the log files, neither of which is any good in > this case. Any pointers would be much appreciated. > One approach for tracking memory overwrites is to add 'sentinel' markers to the beginning and end of each block and check these when you release the block (or at any other time you want to look for memory overwrite). The mechanism for memory problem debugging is to write small functions called something like DebugMemHandleNew, DebugMemHandleFree, etc. These functions take the same parameters as the system functions but do some extra stuff on each memory alloc and release before calling the system functions. 'Extra stuff' varies depending on the problem you're having, but it might be adding four bytes of marker to the beginning and end of each allocated block, or writing a log of each allocation and release (good for tracking lock/release problems). You then create a C header that #defines MemHandleNew to DebugMemHandleNew, etc for each function and add this header to every C file in your project. This mechanism redirects your calls to the memory functions through the debug functions, allowing you to build debug behaviour into the application. It's a good day or two's work, but is reusable for any project after that. At some point I'm sure I'd posted an implementation of this to the list, but it would have been a few years back. This can also give you other information. On one project I used this mechanism to collect statistics on the size of memory chunks and noticed that I was allocating and freeing small temp chunks in significant quantities. A special handler for these improved speed slightly and reduced the memory footprint of the app. Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
