Re: Memory corruption and Dump Stack trace
- From: "karen.b.lin@xxxxxxxxx" <karen.b.lin@xxxxxxxxx>
- Date: Fri, 06 Jul 2007 15:47:44 -0000
On Jul 6, 11:35 am, "karen.b....@xxxxxxxxx" <karen.b....@xxxxxxxxx>
wrote:
On Jul 1, 3:46 pm, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:
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....@xxxxxxxxx" <karen.b....@xxxxxxxxx> wrote:
Hi everyone,
my application has danging pointer, either pointing at something
that's deleted, or the memory was used by someone else. It causes
crashes very randomly and thus hard to reproduce the crash. I
narrowed it down to memory corruption because it crashed at calling a
pointer->doubleValue ...
Is there a way to produce a stack dump in MFC? I want to see who was
trying to delete the object. If anyone has better solution in looking
at this, please help!
Thanks!
Joseph M. Newcomer [MVP]
email: newco...@xxxxxxxxxxxx
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
Hi, Thanks for the tip. Did something along the line as you
suggested. However since the crash is so random, we still to need to
crash this thing and see what addresses go wrong. Does anyone know
how to use
AfxDumpStack(AFX_STACK_DUMP_TARGET_DEFAULT);
I need to use dbghelp.dll or imagehlp.dll to generate image of the
stack. I want to dump the stack when my destructor is called so I can
track who goes in and out to delete my objects. Any idea how I can
use these dll files (and possible .dbg, .pdb files?) with Visual C++?
Thanks in advance~- Hide quoted text -
- Show quoted text -
This is what I've tried:
in Project -> Settings -> Debug -> Additional DLL
I put in
C:\windows\system32\imagehlp.dll
C:\windows\system32\dbghelp.dll
and also
C:\windows\system32\dll\dbghelp.pdb
When I run the debugger, it says "C:\windows\system32\dbghelp.dll does
not contain debugging information" (same for the imagehlp.dll)
and for the pdb file, it says "The target platform of C:\windows
\system32\dll\dbghelp.pdb does not match the current target platform"
No idea what they mean ...
My program does generate a pdb file. How do I put all of these
together?
.
- Follow-Ups:
- Re: Memory corruption and Dump Stack trace
- From: Joseph M . Newcomer
- Re: Memory corruption and Dump Stack trace
- References:
- Memory corruption and Dump Stack trace
- From: karen.b.lin@xxxxxxxxx
- Re: Memory corruption and Dump Stack trace
- From: Joseph M . Newcomer
- Re: Memory corruption and Dump Stack trace
- From: karen.b.lin@xxxxxxxxx
- Memory corruption and Dump Stack trace
- Prev by Date: Re: Memory corruption and Dump Stack trace
- Next by Date: using MXXMLWriter to pretty print xml
- Previous by thread: Re: Memory corruption and Dump Stack trace
- Next by thread: Re: Memory corruption and Dump Stack trace
- Index(es):
Relevant Pages
|
