AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

FastMM und aktuelles Delphi

Ein Thema von Der schöne Günther · begonnen am 5. Jul 2016 · letzter Beitrag vom 12. Apr 2017
Antwort Antwort
Seite 1 von 2  1 2   
Der schöne Günther

Registriert seit: 6. Mär 2013
4.780 Beiträge
 
Delphi 10 Seattle Enterprise
 
#1

FastMM und aktuelles Delphi

  Alt 5. Jul 2016, 18:03
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.

Geändert von Der schöne Günther ( 5. Jul 2016 um 18:11 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.486 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#2

AW: FastMM und aktuelles Delphi

  Alt 5. Jul 2016, 18:14
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 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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie ( 5. Jul 2016 um 18:37 Uhr)
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
4.780 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: FastMM und aktuelles Delphi

  Alt 5. Jul 2016, 20:29
Vielen Dank für die ausführliche Erklärung

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.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
4.780 Beiträge
 
Delphi 10 Seattle Enterprise
 
#4

AW: FastMM und aktuelles Delphi

  Alt 6. Jul 2016, 10:01
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.

Geändert von Der schöne Günther ( 6. Jul 2016 um 10:30 Uhr) Grund: Die Welt wendete sich gegen mich
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
1.921 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#5

AW: FastMM und aktuelles Delphi

  Alt 6. Jul 2016, 11:12
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.486 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#6

AW: FastMM und aktuelles Delphi

  Alt 6. Jul 2016, 15:00
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
4.780 Beiträge
 
Delphi 10 Seattle Enterprise
 
#7

AW: FastMM und aktuelles Delphi

  Alt 6. Jul 2016, 18:19
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?
Angehängte Dateien
Dateityp: zip SeattleCrash.zip (94,7 KB, 8x aufgerufen)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.486 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#8

AW: FastMM und aktuelles Delphi

  Alt 7. Jul 2016, 11:44
Ich lüge aber nicht.
Hab ich auch nicht behauptet - kann es aber immer noch nicht nachstellen - habe Seattle mit Subscription Update 1.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
4.780 Beiträge
 
Delphi 10 Seattle Enterprise
 
#9

AW: FastMM und aktuelles Delphi

  Alt 7. Jul 2016, 12:19
Komisch, dann ist mein PC wohl kaputt. Ist auch halb so wild, XE7 und 10.1 gehen ja. Vielen Dank fur's Mitfiebern
  Mit Zitat antworten Zitat
Headbucket

Registriert seit: 12. Dez 2013
Ort: Dresden
171 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#10

AW: FastMM und aktuelles Delphi

  Alt 12. Apr 2017, 09:29
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
Angehängte Dateien
Dateityp: zip InterfaceFrameTester.zip (155,3 KB, 8x aufgerufen)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:29 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf