FastMM und aktuelles Delphi

[Der schöne Günther]

Delphi 10.1 Berlin.
Datei -> Neu -> Geräteübergreifende Anwendung.

Ich trage in die .DPR-Datei als erste Unit noch FastMM4 ein:

Delphi-Quellcode:

program Project1;

uses
  FastMM4,
  System.StartUpCopy,
  FMX.Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Sobald ich das leere Formular schließe bekomme ich eine AV mit folgendem Stack

Code:

System.TMonitor.Destroy
System.TInstBucket.Finalize
System.TInstHashMap.Finalize
System.Finalization
System.FinalizeUnits
System._Halt0
:00409DC5 System::__linkproc__ Halt0()

Nach dem Zufallsprinzip auch mal an anderen Stellen. Lasst ich FastMM weg, ist im Debugger nichts zu bemerken. In einer VCL-Anwendung ist auch nichts zu bemerken.

Ich habe FastMM noch von Sourceforge geladen:
https://sourceforge.net/projects/fastmm/

Es wäre aber langweilig wenn sich ein Projekt nicht balkanisiert, zu finden auch auf Github:
https://github.com/pleriche/FastMM4 (inkl. 13 Forks)


Kann mir jemand sagen ob ich etwas falsch mache oder funktioniert FastMM auf neueren Versionen nicht mehr?


PS: Ich sehe gerade, ich bin nicht der einzige dem das aufgefallen ist:
https://github.com/pleriche/FastMM4/issues/18

Ich hätte gedacht dass bei so etwas die Welt früher im Fünfeck springt.

[Stevie]

https://github.com/pleriche/FastMM4/issues/18

Die Ursache des Problems ist ganz einfach. Die Hashmap für die weak references in System wird lazy initialized (das erste mal, wenn eine weak reference genutzt wird).
Das passiert irgendwo beim Form erstellen in den Tiefen von FMX (genauer gesagt dort, wo [Weak] an einem Interface Feld steht, so wie in diesem Fall beim TContentInflater<T>).

D.h. der Speicher wird hier vom schon initialisierten FastMM verwaltet.

Das Abräumen der Hashmap passiert aber beim finalization von System und das passiert nach dem finalization der FastMM unit.

Ich hab mal testhalber das

Delphi-Quellcode:

FinalizeMemoryManager

dort auskommentiert und es gibt zumindest keine AV mehr, da auch der Speicher der Weakref Hashmap von FastMM aufgeräumt wird.

Edit: Die Option NeverUninstall (einfach bei den Conditional defines im Projekt hinzufügen) sollte reichen.

[Der schöne Günther]

Vielen Dank für die ausführliche Erklärung :thumb:

Genau das war mein Verdacht, hatte das aber ausgeschlossen da ich fälschlicherweise im Kopf hatte man würde eine spezielle Exception und keine einfache AV bekommen wenn das der Fall ist.

[Der schöne Günther]

Ok, jetzt muss ich doch noch einmal nachbohren.

Auf 10 Seattle (+Update 1) habe ich ein ähnliches Problem. Ich bekomme reproduzierbar beim Beenden der Anwendung eine AV mit folgendem Stack:

Code:

FastMM4.DebugGetMem(???)
System._GetMem(???)
System._NewUnicodeString(???)
:00406DF6 System::__linkproc__ GetMem(Size=????)
System.SysUtils.Format(???,???,$96360C)
System.SysUtils.Format(???,???)
FMX.Presentation.Factory.TPresentationProxyFactory.GeneratePresentationName(TEdit,Platform)
FMX.Presentation.Factory.TPresentationProxyFactory.Unregister(TEdit,Platform,TWinPresentationProxy<FMX.Edit.Win.TWinNativeEdit>)
FMX.Edit.Win.Finalization
System.FinalizeUnits
System._Halt0
:00409A75 System::__linkproc__ Halt0()

NeverUninstall, LeakReporting, CheckHeapForCorruption - Das alles half nichts.


Es ist der Punkt Memory Manager Sharing -> EnableBackwardCompatibleMMSharing. Wenn ich das aktiviere, dann geht es! Die Beschreibung ist

Zitat:

Define this to enable backward compatibility for the memory manager sharing mechanism used by Delphi 2006 and 2007, as well as older FastMM versions.

Wie kommt hier die "older FastMM versions" ins Spiel? Ich dachte, ich bin so modern, ich brauche das nicht. Da lag ich wohl wieder falsch. Kann mir jetzt noch jemand helfen zu verstehen, was hier abläuft und warum ich diesen Eintrag brauche?

Kommando zurück, es bringt doch nichts.

Zum Nachstellen reicht allerdings kein leeres Formular mehr aus, man muss auch einen TTreeView darauf legen und die Größe etwas größer machen. Komische Welt.

[TiGü]

Das Problem hatte ich in unserer neuen VCL-Anwendung auch schon ein paar Mal bemerkt.
Wir verwenden das Delphi eigene Tethering und zusammen mit den FastMM4 hat es an der von Günther beschriebenen Stelle geknallt.

Delphi-Quellcode:

procedure TInstBucket.Finalize;
var
  I: Integer;
begin
  for I := 0 to FCount - 1 do
    FInstItems[I].Free;
  FCount := 0;
  FLock.Destroy; // <--- da knallt's dann!
  SetLength(FInstItems, 0);
end;

Dachte immer wir machen irgendwas falsch und/oder der Entwickler bei Emba hat da fälschlicherweise Destroy anstatt Free aufgerufen.

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1342065)

Zum Nachstellen reicht allerdings kein leeres Formular mehr aus, man muss auch einen TTreeView darauf legen und die Größe etwas größer machen. Komische Welt.

Kann ich nicht nachstellen.

[Der schöne Günther]

Danke für's Ausprobieren. Ich lüge aber nicht.

Embarcadero® RAD Studio 10 Seattle Version 23.0.21418.4207

Mit XE7 kein Problem. Mit 10.1 Berlin kein Problem. Nur 10 Seattle.

Ich habe es mal als Testprojekt angehängt, habe ich alles richtig gemacht?

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1342098)

Ich lüge aber nicht.

Hab ich auch nicht behauptet - kann es aber immer noch nicht nachstellen - habe Seattle mit Subscription Update 1.

[Der schöne Günther]

Komisch, dann ist mein PC wohl kaputt. Ist auch halb so wild, XE7 und 10.1 gehen ja. Vielen Dank fur's Mitfiebern ;-)

[Headbucket]

Hallo zusammen,

ich habe zZ ein ähnliches Problem mit der Verwendung von FastMM in Verbindung mit Frames, welche ein Interface implementieren:

Delphi-Quellcode:

type
  TMyFrame = class(TFrame, IMyInterface)
    lbl1: TLabel;
  private
    { Private-Deklarationen }
  public
    procedure MyInterfaceMethode;
  end;

Ein kleines Testprojekt habe ich angehängt. Beim Beenden der Anwendung bekomme ich eine access violation mit folgendem Stack:

Code:

System._IntfClear(???)
:0040d998 @IntfClear + $10
System.TObject.Free
System.Classes.TComponent.DestroyComponents
Vcl.Forms.DoneApplication
System.SysUtils.DoExitProc
System._Halt0

Ohne FastMM geht alles und auch sonst verwende ich FastMM in sämtlichen Projekten. Aber mit Frames und Interfaces habe ich Probleme... .
Liegt der Fehler bei mir? Falls nicht: Wie kann ich die access violation abstellen? Die Hinweise hier im Thread halfen leider nicht.

Grüße
Headbucket