D 10.1 Berlin: crash with empty FMX application

[tueddy]

Hello,

using FastMM4 in an empty FMX application in Delphi 10.1 Berlin results in crash in procedure TMonitor.Destroy;

steps to reproduce:

• new empty FMX application, target Win32
• Add FastMM4 as first unit in dpr file
• After closing see some FMX memory leaks
• Crash in system.pas

Best regards Dirk

[sglienke]

I just quickly analyzed the issue and it is caused by the fact that the weak references hashmap is lazy initialized which happens when FastMM is already initialized but is finalized in the finalization part of System.pas which happens after the finalization part of FastMM4.pas is run (which calls FinalizeMemoryManager).

So this requires finalizing FastMM later (or not at all as seems to be done for BCB according to the ifdef?) or using the NeverUninstall option?

[masonwheeler]

Wow, how did something that basic make it past both internal testing and the beta?!?

[the-Arioch]

Is it the same as www.translate.ru -> http://www.sql.ru/forum/1162994/grabli-s-fastmm-bds-exe ?

They say to avoid this it needs to ensure the memory manager does not hook into SysUtils neither directly nor via other used units.

[the-Arioch]

From that forum "That is the same: Monitors support is initialized in SysUtils themselves"

[GunSmoker]

Quality Central: https://quality.embarcadero.com/browse/RSP-16796

[obones]

The Quality Central issue says it is resolved in 10.2.2 but has any of you actually checked that it is? I'm asking because I'm currently using 10.2.3, which should contain the fix, and yet, I'm observing the same error message (operation detected after uninstalled) at the end of my VCL application...

[obones]

Well, ok, sorry for the noise, this comes from my own code, a very weird case of interdependencies between interface instances.

[graemeg]

I've got the same issue using Tokyo 10.2. I'll see if my client will allow me to upgrade to 10.2.2 or 10.2.3 and see if that fixes the issue.

[edit] OK, I can confirm I'm on 10.2.2 and the issue still exists here on my environment. So no, the issue doesn't seem to be resolved.

[rplant09485]

Hi,

A somewhat hack (but seems effective) fix for this Makes the finalize routines run later (from the ExitProcessProc routine).

Regards Roger

Change the bottom of FastMM4.pas (including initialize and finalize) with code below. Add a section to the FastMM4Options.inc file.

// FastMM4Options.inc { Enable UseExitProcFinalize to cause late shutdown of the memory manager Good for newer versions of delphi (10.1+), esp with fmx} {$define UseExitProcFinalize}

// FastMM4.pas

{$ifndef PatchBCBTerminate} {$ifdef UseExitProcFinalize} var oldExitProc: procedure();

procedure ExitProcFinalize; begin FinalizeMemoryManager; if assigned(oldExitProc) then oldExitProc; end; {$endif} {$endif}

initialization RunInitializationCode;

finalization {$ifndef PatchBCBTerminate} {$ifdef UseExitProcFinalize} oldExitProc := ExitProcessProc; ExitProcessProc := ExitProcFinalize; {$else} FinalizeMemoryManager; {$endif} {$endif}

end.

[GunSmoker]

While it says that the issue is fixed in 10.2.2 - it is not. Not all FreeMem/Dispose calls were removed in 10.2 and 10.3. Only 10.4 seems to fix this issue completely.

[GunSmoker]

This is fixed in 10.4, so this ticket should probably be closed.