David Schwartz

The built-in FastMM isn't very useful as far as gathering diagnostic info goes. You pretty much need the enhanced version with the debug DLL.

I've never found the status reporting by FastMM to be very useful. It logs a ton of stuff that's all nearly identical and hard to distinguish what varies. I built a tool that does sort of a "cross-tab" on the data (like in Excel) and lets you view the data in a more useful way -- it lists things by object rather than by individual references to unfreed memory blocks. The thing is, most of the references that show up are for down-stream errors that are not related to the root cause. For example, if you fail to free a TStringList that's got a bunch of objects attached, you'll get a bazillion errors on unfreed strings and other crap contained in the stringlist and classes attached to the Objects array, and only one or two hard-to-distinguish references to the stringlist itself. In other situations, it will NEVER show the list responsible for the leaks! However, it does kindly shows you exactly where all of these things were all allocated, but that's often 100% irrelevant -- so you end up on a meaningless wild goose chase. The truth is, 99% of the stuff that FastMM reports is simply NOISE. I just spent 2 hrs the other night trying to track down a group of orphaned objects that I was absolutely certain were being freed. I looked at all of this code, wrote a bunch of tests, stepped through the Free/Destroy code and checked everything I could think of. Finally, I looked at the number of objects being allocated, and then at the number being freed. All of the structures I was looking at that I _thought_ were responsible for the leak showed they were actually freeing up exactly the same number as were being allocated. So I started wondering, "Where else am I allocating things that aren't in these two lists?" Well, it turns out I had a loop that created an object at the top and added it to a list. Then it does some checking, and if it doesn't find anything interesting, it removes the object from the list. At the end, that list's contents were being added to another list where I thought the leaks were coming from. The difference was, the first list was not set to own its objects, while the second list was. This was by design. What I overlooked was the Remove operation in the first list did NOT free the attached objects! Nor did my code. So FastMM generated SEVERAL HUNDRED references to orphaned objects that it found due to 65 objects I removed from a list but forgot to free. And because it was pointing to the orphaned objects, I had no hints as to which list they were from. In actuality, the Remove operation took them OFF of the list, so when FastMM found them, they were just orphaned objects outside of ANY container, located miles away from the last place they were referenced! The only way I was able to track this down was comparing the #allocated objects vs #freed objects on each list, and that led me to one list that allocated more objects than were freed, even though they had been removed from the list. I'm mentioning this because this is probably a very good heuristic to measure right up front that might help track down the source of many leaks way faster than anything else I can think of.

I don't need an executable. It's just that posting the sources here directly take up most of the page and distract from an otherwise useful discussion.

Thanks, I do appreciate this, although a zip file attachment would be a lot easier to work with 😉 That's a LOT of text to scroll through here. I noticed that the DWS project has migrated to BitBucket. Is there anything to be aware of when using it?

@Dany Marmur Thanks! We have DevEx ... what's RTC?

They're scattered across a few hundred source files. It's probably worth taking a look. Do you want to post it here and I can grab it, then you can leave it or delete it later?

some are simple, some are quite complex. The thing is, right now they're embedded in Delphi code on the client side. We want to move them into the server as stored procs, funcs, and views, and then replace the code on the Delphi side with simple calls to those server-side objects, parameterized where needed. (We're preparing to migrate from Oracle to PostgeSQL, and there are tools that can convert server-side assets automatically -- not 100%, but enough to be useful. However, they won't read the Delphi code! So we want to take this opportunity to extract all of this random business logic and other SQL CRUD code from the client side and move it over to the server where it belongs.)

care to elaborate a bit?

I think 10.2.2 broke this, and 10.2.3 didn't fix it. I certainly don't like the idea of having to use 3rd-party addins to fix things that the compiler team broke.