Please shoot at MemoryManagerUnit.pas that abstracts some non-UI logic from FastMMUsageTracker.pas

[jeroenp 26]

I could use some input on https://gist.github.com/jpluimers/b08b65991987d01e1dd1bdb4bf8a33c4

 

Especially on:

- the abstracting of the non-UI logic from https://github.com/pleriche/FastMM4/blob/master/Demos/Usage Tracker/FastMMUsageTracker.pas
- the conversion to JSON: built-in Delphi JSON support does not do records out of the box, but I feel my workaround is cumbersome.

 

There is an example on how to use it for logging memory and processor usage on the console.

[David Schwartz 428]

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.

[Clément 148]

Hi,

Are you using FastMM bundled or downloaded (https://github.com/pleriche/FastMM4) ?
The downloaded version has a lot more options and gives you more information including line numbers, very handy.

 

[David Schwartz 428]

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.