Jonathan Wilson said:
I have a closed source app. I have a .dll plugin for this app (which I am
writing). This plugin contains a bug somewhere which seems to clobber
memory in a "random" fashion (as in, its not clobbering any specific
identifiable piece of memory that I can breakpoint on or anything). Are
there any tools out there that I can use to help track this down?
Anyone got any tips to help with this?
I am presuming that it is a native unmanaged dll. Usually when you are
stomping on "random" locations, it's because you either are using the wrong
calling convention, or you have an uninitialized local variable in your
function (meaning that while you are using a garbage address, it is still
inside your virtual address space)...
Compile a debug version with the following properties:
Compile Properties C/C++ Code Generation: Basic Runtime Checks to both
(stack frame and uninitialized variables) - This fenceposts your functions
(this is usually the default, by the way).
You can also do:
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
// the following allows me to trap memory problems with "new" in C++ -
doesn't work in all cases but it helps YMMV
#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif
You can then check your memory right before you see you are having problems
or right at the end of your functions, which will fire an assertion and
opportunity to debug if there is a memory issue detected by the debug memory
allocation routines.
_ASSERTE(_CrtCheckMemory());
(You can look into the crt debug functions in MSDN for more information.)
None of these options would be included in a release build (_ASSERTE's are
#ifdefed out, /RTC1 is not supported with optimizations enabled).
--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?
