c++ debugging

[bob]

hi,

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.

thanks again for any input or tips.

G

 

[Victor Bazarov]

I have a question I should know the answer to.

I've delivered a working set of c++ libraries/dlls that have been

By the time they are DLLs, most of the traces of their being "C++"
have disappeared, haven't they?

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.

So far no relevance to this newsgroup's main topic...

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.

OK, I noticed the word "pointers". Doesn't make it on topic yet...

Can anybody tell me whats the best way to go about determining if
memory is been corrupted.

Some kind of tool should help you. Tools are OS-specific, most often.
You can probably find a good memory manager with some debugging
capabilities, but then the entire application has to use it. Again,
not enough specificity to be posted in comp.lang.c++...

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.

Yes, it is! You bet your sweet ... it is! Post to the newsgroup
that deals with programming "MS environment" and ask about memory
debugging tools.

V

 

[Kira Yamato]

hi,

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.

thanks again for any input or tips.

G

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.

But in any case, at least you'll be 100% if it were indeed that other
DLL that was trashing your data structure. You will also be able to
see how your data structure is being changed by the DLL too. It's just
that you may not be able to see the code that is changing it, unless
you can read assembly code.

 

[ronipay]

hi,

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.

thanks again for any input or tips.

G

Hi,

Victor has already said that before, but you should really post this
to a Windows development group.
That said, a simple question for you: How does your module interact
with the 3rd party DLLs? Do you dynamically load them in run-time,
using LoadLibrary, or do you compile against .lib files and load
the DLLs in load-time? The solution may be as simple as compiling
your DLL against the up-to-date .lib stub of the 3rd party DLLs.

Roni

 

[ronipay]

hi,

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.

thanks again for any input or tips.

G

Hi,

Victor has already said that before, but you should really post this
to a Windows development group.
That said, a simple question for you: How does your module interact
with the 3rd party DLLs? Do you dynamically load them in run-time,
using LoadLibrary, or do you compile against .lib files and load
the DLLs in load-time? The solution may be as simple as compiling
your DLL against the up-to-date .lib stub of the 3rd party DLLs.

Roni

 

[Puppet_Sock]

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.

Just a thought, noting that it is off topic for this news group.
Can you get two systems running, one with the new DLL and one
with the old? Then you could follow operation line-by-line till
you see a difference between them.
Socks

 

[James Kanze]

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.