[vdug] Re: Frustrating Access Violation Problem (Possible Memory Overwrite)
- From: "Jason Galea" <jason_j_galea@xxxxxxxxxxx>
- To: <vdug@xxxxxxxxxxxxx>
- Date: Tue, 2 Oct 2001 08:38:22 +1000
Guys,
I work with Anthony, and we worked on this one together. It was actually
Anthony who found the bug listing.
After ***much*** frustration and some digging , the problem was eventually
tracked down to a known bug in Delphi 5 (and according to the bug list, all
prior versions as well).
The error had nothing to do with memory overwrite. The issue is with string
arrays. Specifically, there is an error in the address arithmetic that
Delphi uses that only occurs when using arrays (either dynamic or static) of
Strings. If ShortStrings are used, the problem vanishes.
The official bug is bug no 502 -
http://buglist.jrsoftware.org/generated/entry0502.htm.
FYI, the official bug list is kept here -
http://buglist.jrsoftware.org/indexpag.htm.
This was a hard one to find because when it comes to bugs, you should always
assume any code you wrote is at fault. After checking that code for 2 days
(2 people, mind you) and not being able to find fault, it clicked that maybe
it is not our fault at all. Nevertheless, that was the fix.
----- Original Message -----
From: "Karin Rodrigues" <k.rodrigues@xxxxxxxxxx>
To: <vdug@xxxxxxxxxxxxx>
Sent: Friday, September 28, 2001 4:11 PM
Subject: [vdug] Re: Frustrating Access Violation Problem (Possible Memory
Overwrite)
>
> Hi Anthony,
>
> The only times I've ever seen this kind of erratic access violations was
> when there was a try.. finally somewhere that frees an object that hadn't
> been initialised properly. Eg.
>
> try
> ...
> MyObj := TObject.create();
> ...
> finally
> MyObj.Free;
> end;
>
> There could easily be an exception before or during the create, therefore
> the create should be before the try, or MyObj set to nil before the try.
If
> MyObj had been used elsewhere and had been freed (not FreeAndNil) then it
> could still be assigned, but the pointer is invalid. So it will
arbitrarily
> free some other object's memory. I'm sure you know all of this already. Of
> course you can have a similar problem without a try..finally, but it's the
> most common.
>
> Cheers,
> Karin
>
> -----Original Message-----
> From: vdug-bounce@xxxxxxxxxxxxx [mailto:vdug-bounce@xxxxxxxxxxxxx]On
> Behalf Of Anthony_Egerton@xxxxxxxx
> Sent: Thursday, 27 September 2001 18:43
> To: vdug@xxxxxxxxxxxxx
> Subject: [vdug] Frustrating Access Violation Problem (Possible Memory
> Overwrite)
>
>
>
> We've just started using DUnit for automated unit testing. A good and
> noble thing.
> Unfortunately we've found a problem. (Or fortunately depending on your
> philosophy of finding bugs)
> When we run the same tests a certain number of times, and after so many
> executions of the same test we start getting Access Violations.
> The Access Violations don't happen at the same point in the code every
> time.
> We fixed a memory leak and the Access Violations stopped appearing.
> My suspicion is that some memory is being overwritten, and the Access
> Violations occur when we encounter the overwritten memory.
>
> The question is how do we find where this is happening?
> Any suggestions would be appreciated at this point (I'm flat out of
> ideas).
>
> We have tried running it in AQTime memory profiling and MemProof to
> hopefully find the memory overwrites. All we did find was a memory leak.
> (Good to find, but not what we were after!)
>
> Thanks in advance,
> Anthony
>
============================================================================
> ==========
>
> "The information contained in this e-mail message may be confidential
> information, and may also be privileged. If you are not the intended
> recipient, any use, interference with, disclosure or copying of this
> material is unauthorised and prohibited. If you have received this
message
> in error, please notify us by return email and delete the original
message."
>
>
>
Other related posts:
