Add FastMM_ProcessAllPendingFrees() to exports in BorlndMM.dpr

[PeterJanRoes]

The documentation of FastMM_WalkBlocks() states that FastMM_ProcessAllPendingFrees() should be called first in order to not report blocks that are already freed but pending. BorlndMM.dpr exports FastMM_WalkBlocks() but it does not export FastMM_ProcessAllPendingFrees().

[pleriche]

Hi, thanks for letting me know - I have added it.

[PeterJanRoes]

Hi, great, thank you for adding! I hoped adding this call to FastMM_ProcessAllPendingFrees() would get rid of some allocated blocks in FastMM_WalkBlocks(), but unfortunately it does not. It turns out that the uses of SysUtils in BorlndMM.dpr adds a bit over 80 allocations from System.SysConst. Removing SysUtils solves this, but given the comment I guess it is there for a reason. I removed the unit from the imports and everything seems to work fine, I even get EOutOfMemory when expected. Is this unit still needed? Also in a release build?

[pleriche]

I built BorlndMM.dll in debug mode and used it together with this small test application:

program Project1;

{$APPTYPE CONSOLE}

uses
  ShareMem,
  System.SysUtils;

procedure LeakMemory;
begin
  TObject.Create;
end;

begin
  LeakMemory;
end.

The only leak I got was the expected TObject leak:

I suspect there's something else going wrong with your application.

[PeterJanRoes]

Yes, I know that when using the leak detection of FastMM there is no leak, as System.SysUtils already will be unloaded again at the time of the standard leak reporting. However, I am talking about calling FastMM_WalkBlocks() right after loading the DLL, or before finalizing. This reports the blocks (still) allocated by System.SysUtils, not leaks per se, which is a bit inconvenient. And my real question is whether the import of System.SysUtils really is necessary (as the comment indicates) or not. I did some superficial tests, and had not problems with leaving out the import.

[pleriche]

Ah, sorry, I misunderstood. I wrongly inferred that you meant that the blocks leak.

With System.SysUtils in the "uses" clause if e.g. the FastMM_EnterDebugMode call in the initialization section raises an exception then the application correctly reports the exception:

Without it you get a runtime error:

Admittedly, the likelihood of the unit initialization code raising an exception is low, and the consequences are not particularly dire. I reckon it's fine to remove it.

[PeterJanRoes]

Okay, clear. Thank you!