Is there a way to programmatically tell if particular block of memory was not freed by FastMM?

Question

I am trying to detect if a block of memory was not freed. Of course, the manager tells me that by dialog box or log file, but what if I would like to store results in a database? For example I would like to have in a database table a names of routines which allocated given blocks.

After reading a documentation of FastMM I know that since version 4.98 we have a possibility to be notified by manager about memory allocations, frees and reallocations as they occur. For example OnDebugFreeMemFinish event is passing to us a PFullDebugBlockHeader which contains useful informations. There is one thing that PFullDebugBlockHeader is missing - the information if the given block was freed by the application.

Unless OnDebugFreeMemFinish is called only for not freed blocks? This is which I do not know and would like to find out.

The problem is that even hooking into OnDebugFreeMemFinish event I was unable to find out if the block was freed or not.

Here is an example:

program MemLeakTest;

{$APPTYPE CONSOLE}

uses
  FastMM4, ExceptionLog, SysUtils;


procedure MemFreeEvent(APHeaderFreedBlock: PFullDebugBlockHeader; AResult: Integer);
begin
//This is executed at the end, but how should I know that this block should be freed
//by application? Unless this is executed ONLY for not freed blocks.
end;

procedure Leak;
var
  MyObject: TObject;
begin
  MyObject := TObject.Create;
end;

begin
  OnDebugFreeMemFinish := MemFreeEvent;
  Leak;
end.

What I am missing is the callback like:

procedure OnMemoryLeak(APointer: PFullDebugBlockHeader);

After browsing the source of FastMM I saw that there is a procedure:

procedure LogMemoryLeakOrAllocatedBlock(APointer: PFullDebugBlockHeader; IsALeak: Boolean);

which could be overriden, but maybe there is an easier way?

Fakieh

Use the full FastMM with appropriate settings and you will receive a detailed report of all leaked blocks at shutdown. Is this not sufficient for your needs? – Heathenish

No, as I wrote: "Leak is reported as expected on closing the application" and this is not I want. I want to log it by myself. – Fakieh

I have always understood that FastMM can only make this check as the VERY LAST action that the program should make - by definition - so by the time FastMM makes its report your code has finished. To get a partial solution you can always take a look in their source to see how allocated memory is flagged. – Reposeful

Reported as expected leak? Did you register it as expected. Also you can't decide that memory is leaked until shutdown, unless you provide complex logic that understands expected lifetimes. – Heathenish

Sorry for not beeing clear enough, the leak was not registered in expected leaks collection. What I've meant is that the LogErrorsToFile option in FASTMM4Options.inc is working properly. I'have the environment setup up properly. What I would like to do is to have for example a custom logging. After reading a source of FastMM I think I know how to do this, I just thought that it might be easier way. – Fakieh

@Brian yes that is what I did, but I thought I'll ask anyway to exchange ideas. – Fakieh

If OnDebugFreeMemFinish is called that means that the block was freed. There is no OnMemoryLeak event. There could never be such an event. What FastMM does is, on shutdown, determine that any blocks that have not been freed must be leaks. It cannot detect a leak any earlier than that. – Heathenish

Whenever FastMM tells me there is a memory leak, I down tools and fix it immediately. If you don't do that then you'll find it hard to reproduce the leak. If you really wish to log to database then you'll need to look at the CheckBlocksOnShutdown function. Another potential extension point is AppendEventLog but you'll need to modify the FastMM source I suspect. – Heathenish

Erm just pick the file up, parse it and put it in the DB? – Aurelio

use eurekalog for advanced memory leak catching. – Leukoderma

The only way a run-time check of an existing leak would be even remotely useful/fiesible is if a worker thread allocated some memory and then at a later time wanted to check if that memory had already been freed before terminating itself. But what if the memory WAS freed and then reused by FastMM for a new allocation before the leak could be checked? Better for the thread to simply keep track locally of its own allocations and know if it freed them or not. No point in asking FastMM for that information. – Gehlbach

VMMap helped me with something similar. My app was raising out of memory and FastMM did not warned me of leak on app shutdown (correctly, because was not a leak). Would need to write an answer for details, but since this was not the question.. basically I converted map file to dbg (look for map2dbg.exe), configure dbg folder in VMMap, opened the app with VMMap, do some operations, see Trace button in VMMap and order for Bytes. It showed me the callstacks of the operations that most allocated memory. Again, not leak, because was freed when app was closed, but I found my problem. – Instalment

Answer 1

Even if such handler exist, it would be nearly useless, as everything, including DB would be shut down at the time when FastMM reports leaks.

So, I suggest you to turn on LogErrorsToFile along with FullDebugMode conditionals in FastMM4Options.inc. This will give you a text file with leaks, which later you can parse and put into DB.

Perfuse