Any ideas on tracking down memory corruption

[depkefamily]

I have a large C++ program using multiple vendors DLLs which is giving
me a major
headache. Under release mode I get exceptions thrown from what looks
like a dereferenced
corrupt pointer. The problem is that when I change the inputs the
location of the corruption
moves, looking to me like someone is trashing memory and then later I
see the results. The
location also shifts when I change some of the code, although I have
been unable to see the pattern.

I am running on Windows 2000 using Visual C++ 6.0 SP3 and the latest
update of Purfify
Plus. Purify is able to give me a stack trace at the point of the
exception but not when the
memory gets corrupted(which I presume is happening). I have yet to
reproduce the problem in
debug mode.

This all started when I got the latest version of a DLL from one of the
vendors. I tried taking it
up with them but they want me to produce a test case for them. If it
weren't for their
reputation I would be more skeptical of their code but at this point I
can only be suspicious.
Is it possible that there is a conflict in running the combination of
DLLs, and if so how do you
figure out what the problem is. All of the DLLs contain proprietary
code which I do not have.

I thought purify could/should catch something like this. What do you
all use in situations like
this? Aside from shifting some code around and creating objects at
various places on the
heap and stack til I find the pattern, I am at a loss. Also I am not
running out of memory,
already checked that.

Thanks, I am very curious to see what techniques others use.

Tom

 

[Victor Bazarov]

I have a large C++ program using multiple vendors DLLs which is giving
me a major
headache. Under release mode I get exceptions thrown from what looks
like a dereferenced
corrupt pointer. [...]

I thought purify could/should catch something like this. What do you
all use in situations like
this? Aside from shifting some code around and creating objects at
various places on the
heap and stack til I find the pattern, I am at a loss. Also I am not
running out of memory,
already checked that.

If the behaviour is reproducible with the same data, and you know which
pointer is corrupted, stop right after the pointer is created and set to
its proper value (if you know what and where it is), and then create
a breakpoint for changes in that variable, if your debugger allows that.
The execution is going to be slow after that, but if the behaviour is
not time- or performace-sensitive, you should be able to pinpoint the
code that screws with this pointer (directly or by overrunning some other
memory).

The difference between debug and release modes also is a hint: in some
cases in debug mode all variables are initialised to something (like 0),
and in release they are not, that can play a role, so look for the uses
of uninitialised objects (even if it's just a 'bool' variable).

V

 

[Tom]

Can you setup breakpoints in VS 6.0 built under release mode? I just
tried and when
the app starts all break points are disabled.

 

[Victor Bazarov]

Can you setup breakpoints in VS 6.0 built under release mode? I just
tried and when
the app starts all break points are disabled.

This is compiler-specific. Please go to 'microsoft.public.vc.*'
hierarchy and find an appropriate newsgroup to talk about those.

V

 

[Paul]

Can you setup breakpoints in VS 6.0 built under release mode? I just
tried and when
the app starts all break points are disabled.

So how about changing the release mode settings to settings that allow
debugging to be built into your app? (Note that this is a hint to you as to
how to solve your problem -- please ask further questions concerning this in
Visual C++ related newsgroups)..

- Paul

 

[Tom]

I can follow up on this in the VS groups, but I didn't think this had
anything to do with
their compiler. If I were to use g++ or other compiler and not include
the symbol table,
which is what release mode does, how would you set break points as was
suggested?
I was just seeking general techniques on tracking down memory bugs.

 

[Victor Bazarov]

I can follow up on this in the VS groups, but I didn't think this had
anything to do with
their compiler.

If debugging information weren't compiler-speicific, we'd have it defined
in the Stadnard. As it stands, no debugging information is even mentioned
in the Standard document. That means that it doesn't have to even exist.

If I were to use g++ or other compiler and not include
the symbol table,
which is what release mode does, how would you set break points as was
suggested?

Ask in a g++ newsgroup. Or other compiler newsgroup. There is a way to
make the compiler generate "symbol table" or whatever else goes into the
debugging information even in "release mode".

I was just seeking general techniques on tracking down memory bugs.

I gave you one. Now, how to do it with a particular compiler is not topical
here. So please stop asking. Nobody can answer it here without veering off
topic. Go to your compiler's newsgroup.

V