FeatureRequest: create a "Delta" report for memory allocations

[HHasenack]

As you can probably guess I am fighting a spurious memory leak in my (or 3rd party?) code, and the memory leak is only there during / after complicated multithreaded execution of an analysis routine (and therefore ever increasing memory footprint upon running the same complicated routine with the same data over and over again).
Unfortunately the memory leak does NOT surface there when the app closes.

What would be very useful is to have a statistical delta report between two "Allocation group" values.
I am currently using the FastMM_LogStateToFile to generate reports, but it is very hard to analyze as many objects get destroyed and reallocated, causing the report to be lengthy and complicated.

So. What I actually want to know is the delta of "living" objects/allocations between 2 different Allocationgroups. (Which I use as kind-of memory state benchmarks)
Delta coult be count , total memory or both.

Or maybe there is a far better approach to finding the source of my problem.

Thanks for helping me out

Hans
(Registered as S&G Asset Management)

[pleriche]

If I were to rename AMinimumAllocationGroup and AMaximumAllocationGroup to AAddFromAllocationGroup and AAddUpToAllocationGroup, and then also add ASubtractFromAllocationGroup and ASubtractUpToAllocationGroup parameters, would that help?

The idea is that allocations in groups AAddFromAllocationGroup through AAddUpToAllocationGroup are added and allocations in groups ASubtractFromAllocationGroup through ASubtractUpToAllocationGroup are subtracted. So it is in effect a diff.

[pleriche]

I have pushed this addition to the repository.

[HHasenack]

Whoa faster than a lighning bolt :>
... I'm gonne investigate this right away. Thx Pierre

[HHasenack]

FastMM_117471859.txt
So... I have been playing a little with the new FastMM_LogStateToFile , but somehow the generated file does not show what I expeced when calling it multiple times.

I call 'FastMM_LogStateToFile' in principle with

  AAddUsageInAllocationGroupsFrom = FastMM_CurrentAllocationGroup
  AAddUsageInAllocationGroupsUpTo =FastMM_CurrentAllocationGroup
  ASubtractUsageInAllocationGroupsFrom = 0
  ASubtractUsageInAllocationGroupsUpTo = FastMM_CurrentAllocationGroup-1

Then after calling 'FastMM_LogStateToFile' Increase the value of the global FastMM_CurrentAllocationGroup in order to find out (statistically) the delta of objects of a certain class , where delta<>0

So I would expect when executing this without running any complicated code in between that there would be (close to) no items listed. Instead I get a relatively long list of objects that were not touched/executed in between the calls.

Either I do not understand the usage of the parameters, or FastMM has an issue trouble finding the right node to "subtract" or something like that.

Or, my app is (and the RTL and VCL) are leaking big time. see FastMM_LogStateToFile attached file.

[pleriche]

If I understand correctly what you want to do, then I believe these are the settings you should use:

  AAddUsageInAllocationGroupsFrom = 0
  AAddUsageInAllocationGroupsUpTo = FastMM_CurrentAllocationGroup
  ASubtractUsageInAllocationGroupsFrom = 0
  ASubtractUsageInAllocationGroupsUpTo = FastMM_CurrentAllocationGroup - 1

[HHasenack]

Hi Pierre

Yes, this was just what I needed. I have located my memory leak!
Unfortunately I did not find a solution yet (something with omnithreadlibrary), but that should not be your concern :)

Thanks for the fast responses & solutions!

Yet another question: is it possible to have a detailed report (like the one for the detailed memory leaks when the app closes) for this in-between report? I just hope those stack dumps will help me with my investigation.

[pleriche]

Hi Hans

I've never considered adding the detail to the usage report, because generally it would be a massive report and would be difficult to parse, Even the "differential" usage report would still be large since all the blocks would still need to be included because I cannot reliably tell which blocks in the included and excluded allocation groups should cancel each other out.

What I would do in your scenario is to create a debug version of the application that logs the memory usage in key areas so you can narrow it down until you find the exact spot. If you really want the stack traces for all allocated blocks you can get that from FastMM_WalkBlocks, but the sheer volume may be a problem.