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/
