Enable Guard Malloc (was Re: Isolating a bug?)

FROM : daniel
DATE : Wed Apr 06 18:31:18 2005

I thought random memory stompers were hard to track down, too.  At
least, until I noticed just yesterday that I've been glancing right
over the "Enable Guard Malloc" option in the Xcode debug menu.

I had a random memory smasher that I was dreading.  The MallocHelp
related utilities did nothing for me, so I was looking forward to
slowly and painfully paring down my program in a way that would
preserve the bug but reduce the amount of examinable code.

Then I did a web search where I noticed somebody mentioning the "guard
malloc" feature (man libgmalloc for more info).  This feature is like a
super-paranoid "guard edges" feature.  From the man page:

   When memory is freed, libgmalloc deallocates its
   virtual memory, causing reads or writes to the freed buffer cause a bus
   error.  Thus, nasty, hard-to-track-down bugs are immediately obvious,
and
   you'll know exactly which code is causing the problem.

I switched it on, ran the program, and located the memory stomping code
on the first try.  I'm surprised this isn't mentioned in the "Mac OS X
Debugging Magic" technote.  Perhaps since it's included in a clearly
visible Xcode menu, it's not considered "magic."  I feel pretty
embarrassed now for not knowing about it, but I will certainly never
forget it.

I'm sure there are "memory stompers" of some kind that fall outside of
the scope of this tool's usefulness, but I am guessing that the vast
majority of memory stompers will be located by enabling this tool and
simply waiting.  Grab some coffee while your application launches.

Daniel


On Apr 6, 2005, at 4:41 AM, Ondra Cada wrote:

> If that does not help, I kind of fear the problem *may* be elsewhere,
> in an uninitialized pointer or somrthing alike, whose result are
> mangled in-memory data. That's a bug alas very difficult to find, and
> assembly-level debugging might be needed. Well, hopefully, the cause
> would be something more trivial :)