How to find smashed memory?

Delphi 5, large packaged application.

A programer's nightmare. Something I have done is overwriting memory.
The symptom will not sit still.

Sometimes I can get a repeatable situation, and see exactly what is
getting smashed (eg MyTable.Field[X].FieldName). But the moment I put
any additional code in place, it moves around.

So it seems like: if I can get one of the repeatable situations
active, then set a "memory changed" breakpoint, I might have a hope of
seeing who/where the culprit is.

However, there are few simple variables, almost everything is accessed
via some method. Thus I find the Delphi "Memory Watch/Break When
Changed" difficult (impossible) to use.

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.

Long ago under DOS I was able to kill this problem by knowing roughly
what area was gettin smashed, setting 'memory changed' breakpoints
over that area, and seeing what line I was executing when the memory
was overwritten.

I am unable to find a similar tool/approach for windows/Delphi.

Any suggestions? Many thanks in advance.

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

.

Hello!

While debugging my program, I now am unable to view the values of my
variables. This affects my watchlists and evaluate dialogs. I am
guessing that one of my compiler settings is set wrong but maybe it is
caused by something else. What do you recommend I do?

Here are my Compiler tab settings:

Code Generation
Optimization: Off
Aligned record fields: On
Stack Frames: Off
Pentium Safe FDIV: Off

Syntax options
Strict Var-strings: On
Complete boolean eval: Off
Extended Syntax: On
Typed operator : Off
Open Parameters: On
Huge Strings: On
Assignable typed constraints: On

Runtime errors
Range checking: Off
I/O checking: On
Overflow checking: Off

Debugging
Debug Information: On
Local Symbols: Off
Reference Info: On
Assertions: On
Use Debug DCUs: Off

Messages
Show hints: On
Show warnings: On


Thanks in advance!

Tom Nesler

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

.

Steward wrote:
> Delphi 5, large packaged application.
>
> A programer's nightmare. Something I have done is overwriting memory.
> The symptom will not sit still.
>
> Sometimes I can get a repeatable situation, and see exactly what is
> getting smashed (eg MyTable.Field[X].FieldName). But the moment I put
> any additional code in place, it moves around.
>
> So it seems like: if I can get one of the repeatable situations
> active, then set a "memory changed" breakpoint, I might have a hope of
> seeing who/where the culprit is.
>
> However, there are few simple variables, almost everything is accessed
> via some method. Thus I find the Delphi "Memory Watch/Break When
>; Changed" difficult (impossible) to use.
>;
> 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.
>
> Long ago under DOS I was able to kill this problem by knowing roughly
> what area was gettin smashed, setting 'memory changed' breakpoints
> over that area, and seeing what line I was executing when the memory
> was overwritten.
>
> I am unable to find a similar tool/approach for windows/Delphi.
>;
> Any suggestions? Many thanks in advance.

If this were C++, I'd recommend writing a custom memory allocator and
use 0xDEADBEEF or the like to surround the memory (or, personally, I'd
just use Safe C++ and completely avoid this sort of problem in the first
place). At any rate, while I'm not sure how you would introduce a
custom memory allocator in Delphi, it would look roughly like:

Your application requests 15 bytes of memory.
Custom memory allocator allocates 27 bytes (8 + 15 + 4) of memory.
The first 4 bytes are how many bytes total are allocated, the next 4
contain 0xDEADBEEF, and the last 4 contain 0xDEADBEEF.
The custom allocator returns a pointer to the 15 bytes of memory to the
application. From the application's perspective, it gets 15 bytes of
memory.

The 0xDEADBEEF's act as 4-byte buffer zones. If they are altered, then
your program has stepped outside the legitimate boundaries. You can
write another function that takes a pointer and determines if the memory
has been altered before using it. The same function can be used by the
custom allocator's function that frees the memory. You can throw a
breakpoint in the function for when memory has been altered that
shouldn't have been.

This approach uses significantly more memory (and probably more CPU) -
obviously not to be used in release-mode compilations. Some tools use
this approach when they hook Win32 API calls such as GlobalAlloc(),
VirtualAlloc(), etc.

Since I started using Safe C++, this is no longer an issue for me. The
same principles I use for C++ are adaptable to most languages, even
Delphi (despite the C++ in the name). Sorry I'm not much help here (I
do most of my stuff in C++ or PHP) but hopefully it gives you an idea or
two. Quick Google search turned up:

http://www.oreilly.com/catalog/delphi/chapter/ch02.html

Has an example (near the bottom) of a custom memory manager for Delphi.

--
Thomas Hruska
CubicleSoft President
Ph: 517-803-4197

*NEW* VerifyMyPC 2.5
Change tracking and management tool.
Reduce tech. support times from 2 hours to 5 minutes.

http://www.CubicleSoft.com/VerifyMyPC/

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

.

Can you post the MemCheck log when it bombs please? (Make sure
everything is built with TD32 debug info on, and as much debugging info
included as possible, so the memcheck log is more useful than it would
otherwise be please.)

Walter

Steward wrote:
>
>
> 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.
>
>

[Non-text portions of this message have been removed]

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

.

Walter Prins wrote:
> Can you post the MemCheck log when it bombs please? (Make sure
> everything is built with TD32 debug info on, and as much debugging info
> included as possible, so the memcheck log is more useful than it would
> otherwise be please.)
>
> Walter
>
> Steward wrote:
>>
>> 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.

>From what I read, it seemed like the application wasn't crashing at all
but was just corrupting its own memory. It would be nice if the OP
(Steward) could clarify this.

--
Thomas Hruska
CubicleSoft President
Ph: 517-803-4197

*NEW* VerifyMyPC 2.5
Change tracking and management tool.
Reduce tech. support times from 2 hours to 5 minutes.

http://www.CubicleSoft.com/VerifyMyPC/

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

.