Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

D 10.1 Berlin: crash with empty FMX application #18

Open
tueddy opened this issue Apr 28, 2016 · 11 comments
Open

D 10.1 Berlin: crash with empty FMX application #18

tueddy opened this issue Apr 28, 2016 · 11 comments

Comments

@tueddy
Copy link

tueddy commented Apr 28, 2016

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

crash

Best regards
Dirk

@sglienke
Copy link

sglienke commented Jul 5, 2016

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
Copy link

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

@the-Arioch
Copy link

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
Copy link

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

@GunSmoker
Copy link

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

@obones
Copy link

obones commented Nov 20, 2018

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
Copy link

obones commented Nov 20, 2018

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

@graemeg
Copy link

graemeg commented Dec 13, 2018

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
Copy link

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
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants