Re: Memory corruption and Dump Stack trace

Memory damage bugs rank among the most difficult and intractable bugs that exist. There
is nothing good about them. The worst part is what you observed, that they are random and
hard to reproduce.

First, if this is happening post-deployment, the simplest method is to use DrWatson to
create a dump file. This would be one of the first things I would try. If it happens on
your development machine, you can use JIT (Just-In-Time) debugging to invoke the debugger
at the point of crash.

One way to deal with dangling pointers is to make sure that after every delete you set the
pointer to the thing you deleted to NULL. This doesn't help you if there are multiple
pointers, alas.

One thing I did some years ago (when I used to get these all the time) was create a
"honeypot" object, an intermediate object that represented my object. It's a bit ugly and
wasteful of storage, but what I did was convert all references of the form
        thing->field
to
        thing->honeypot->value->field
and when I did a free (not delete, since this was pre-C++ for me) I would do
        free(thing->honeypot->value);
and set
        thing->honeypot->value = NULL;
now I'd get a NULL-pointer access failure if I used the dangling pointer. My approach was
a bit more elaborate, in that I would require that no one ever actually call free
directly, but instead it would be
        FreeThing(thing);
#define FreeThing(x) _FreeThing(x, __FILE__, __LINE__)
where
        void _FreeThing(Thing * thing, char * file, int line)
            {
                     thing->honeypot->freepoint.file = file;
             thing->honeypot->freepoint.line = line;
                     free(thing->honeypot->value;
            thing->honypot->value = NULL;
                    }

Now if I got a null-pointer access, the freepoint struct gave me the file and line.

Honeypots just accumulated, and were never freed, so the program would grow and grow, but
since this would reasonably quickly find the problem, it didn't matter. A bit of
finagling of macros and #ifdef _DEBUG meant that in the release version, the honeypot got
deleted also. Today in C++ I could hide a lot of that inside classes.

Another solution, often simpler, is simply to add the following to your OnIdle handler:
        ASSERT(_heapchk() == HEAPOK);
(check the docs for the correct spellings here...I'm typing this from memory). That way
if there is any heap damage, you catch it early, insted of waiting for it to nuke you much
later.
                                joe

On Sun, 01 Jul 2007 11:55:54 -0700, "karen.b....@gmail.com" <karen.b....@gmail.com> wrote:


Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm