Re: c++ debugging
On Oct 5, 8:19 pm, Kira Yamato <kira...@earthlink.net> wrote:
On 2007-10-05 04:25:57 -0400, "b...@blah.com" <GrahamJWa...@gmail.com> sa=
id:
I have a question I should know the answer to.
I've delivered a working set of c++ libraries/dlls that have been
fully tested and validated. Now my problem is that somebody else has
been furiously fixing memory leaks and what not in another DLL that is
used by my own. I suddenly find myself in the situation where MY dll's
are now crashing out and I'm fairly sure, that the fixes in the other
DLL have hosed my stuff. I'm thinking its trampling on memory or
corrupting the heap.
I would like to determine if this is the case. Though I'm not sure how
to go about it. All of a sudden, all my pointers are pointing to
invalid data/memory and I'm getting crashest with even the SIMPLEST of
tests.
Can anybody tell me whats the best way to go about determining if
memory is been corrupted. I feel bad asking this as I should really
know the answer! :( Ideally I'd like to know precisely the point in
time that somebody writes to MY memory or corrupts it. I've put
breakpoints in dtors to see if anybody is explitly deleting my objects
but thats come up blank.
I'm working in a MS environment, but thats not realy important here.
Since you're using MS stuff, my comment below may not be relevant.
However, I'll say it hoping that someone may know its equivalence in
the MS world.
In gdb --- a debugger for C++ that I use on the UNIX platform --- there
is such a thing called a *watchpoint* , where you ask the debugger to
examine the value of some expression at every step of execution and to
break the program whenever this value changes.
So, you can set a watchpoint on one of your data-structure. If
anything changes it, the program will break immediately. However, if
it does break inside the other fellow's non-debugging DLL, then you may
just see assembly codes.
There are much more efficient tools for this sort of problem.
Under Linux, we use valgrind, and under Solaris (and Windows
too, I think, although I don't work on that end), Purify. Of
course, Purify isn't free, but it's a lot less expensive that he
is.
But in any case, at least you'll be 100% if it were indeed that other
DLL that was trashing your data structure.
No you won't. Suppose, for example, you pass a function in the
DLL a bad pointer.
In fact, what I suspect is that his code uses pointers after the
other DLL has declared them invalid. Which used to work because
the other DLL leaked the memory behind the pointer. But it's
really a question of contract between the DLL's; who is
responsible for what, and what are the lifetimes of the objects
passed between the two subsystems.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34