RE: How to find smashed memory?

>I have tried EurekaLog, MemProof and MemCheck (tools available via
>google), but ended up drowning in a flood of information which is
>either irrelevant or meaningless to me.
>
>What are people using to debug errors like this? Since I am
>overwriting "my own" memory space, no red flags are raised when the
>damage is done. It is only later, when the program tries to use the
>trashed memory, that mayhem occurs.

There are some problems you can run into in this area that are
totally out of your control when you are using other peoples
software, like Borland components. Sometimes the best you can
do is avoid the situation that causes the problem through a
workaround.

The way I do this kind of thing is have backups of all previous
versions of software that I produce. When I run into a problem,
I verify that the previous version does not have the problem.
I use WinDiff or FC to compare the old and new source to
find what I changed. I then start with the old version and make
the changes one at a time, testing the program after each
change. I usually am able to find exactly which change produced
the error. Often all I have to do is just do the same thing in a
little bit different way to avoid the error.

Glenn Lawler
www.incodesystems.com

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Thank you for this reply.

In this case, the code is seven years old with no recent changes. It
seems to be new data which has exposed the bug.

Your technique is tried and true, I have used it before. Trouble is,
it leaves me open to making the same mistake again. I need to discover
my error if at all possible.

Good advice thanks again. But in this case I hope to lean on the
group, and learn how to use some of the debugging tools and techniques
for truly finding the error.

Wish me luck!

> There are some problems you can run into in this area that are
> totally out of your control when you are using other peoples
> software, like Borland components. Sometimes the best you can
> do is avoid the situation that causes the problem through a
> workaround.
>
> The way I do this kind of thing is have backups of all previous
> versions of software that I produce. When I run into a problem,
> I verify that the previous version does not have the problem.
> I use WinDiff or FC to compare the old and new source to
> find what I changed. I then start with the old version and make
>; the changes one at a time, testing the program after each
>; change. I usually am able to find exactly which change produced
> the error. Often all I have to do is just do the same thing in a
> little bit different way to avoid the error.
>
> Glenn Lawler
> www.incodesystems.com
>

Messages in this topic (0) Reply (via web post) | Start a new topic

.