Was mache ich mit der MemoryLeak Ausgabe?

[Sherlock]

Hi,
ich habe mal zum Spaß und aus Neugier

Delphi-Quellcode:

System.ReportMemoryLeaksOnShutdown := True;

gesetzt. Die Ausgabe erscheint mir jetzt nicht so wirklich hilfreich zu sein.

Zitat:

---------------------------
Unexpected Memory Leak
---------------------------
An unexpected memory leak has occurred. The unexpected small block leaks are:


1 - 12 bytes: TCompleteEventsWrapper x 2, TObject x 2, TCanvasDestroyListenerProxy x 405
13 - 20 bytes: UnicodeString x 430, Unknown x 405
21 - 28 bytes: TThreadPool.TControlFlag x 2, TCTGPainter.Execute$97$ActRec x 1, TGradientPoints x 2, TGradientPoint x 4, TLightweightEvent x 2, UnicodeString x 1223
29 - 36 bytes: TBrushBitmap x 2, TGradient x 2, TD2DBitmapHandle x 2, TCriticalSection x 1, TBitmapImage x 7, UnicodeString x 2431
37 - 44 bytes: TBrushResource x 2, TPosition x 12, TFont x 811
45 - 52 bytes: TList<FMX.Objects.TImage> x 1, TList<FMX.StdCtrls.TLabel> x 1, TBitmap x 7, TList<System.Classes.TCollectionItem> x 2, TList<FMX.TextLayout.TTextAttributedRange> x 404, TBounds x 403, UnicodeString x 404
53 - 60 bytes: TBrush x 1, TObjectList<FMX.Graphics.TCanvasSaveState> x 1, TList<FMX.TextLayout.TTextAttributedRange> x 1, TBounds x 2, Unknown x 4
61 - 68 bytes: Unknown x 2
69 - 76 bytes: TTransform x 2, TTask x 2, TStringList x 405
77 - 84 bytes: TStrokeBrush x 1, TDataGetter x 1
85 - 92 bytes: TDevPainter x 1
93 - 100 bytes: UnicodeString x 403
157 - 172 bytes: TTextLayoutD2D x 405
205 - 220 bytes: UnicodeString x 1
221 - 236 bytes: Unknown x 403
237 - 252 bytes: TCanvasD2D x 1, UnicodeString x 2116
253 - 268 bytes: UnicodeString x 3
349 - 380 bytes: TDevGrid x 1

The sizes of unexpected leaked medium and large blocks are: 11564, 21292, 9260


---------------------------
OK
---------------------------

:glaskugel:
Was davon ist meine Schuld? Da taucht keine meiner Klassen oder Objekte auf, bis auf TDevPainter und TDevGrid...

Sherlock

[Memnarch]

Also zuerst solltest du dich immer um deine kümmern. Die sind praktisch die Roots für weitere leaks. Danach wirds erst spannend.

[Ghostwalker]

Zitat:

Zitat von Sherlock (Beitrag 1353331)

Hi,
ich habe mal zum Spaß und aus Neugier

Delphi-Quellcode:

System.ReportMemoryLeaksOnShutdown := True;

gesetzt. Die Ausgabe erscheint mir jetzt nicht so wirklich hilfreich zu sein.

:glaskugel:
Was davon ist meine Schuld? Da taucht keine meiner Klassen oder Objekte auf, bis auf TDevPainter und TDevGrid...

Sherlock

Wenn Embacadero nicht in den neuen Versionen Mist gebaut hat, alles.:shock:

Am Beispiel TStringList:

gugg mal wo du die überall benutzt (auch komponenten, als Parameter usw).

ein Paradebeispiel für so ein Leak:

Delphi-Quellcode:

   :
   :

Procedure DoSomethingWithTheList(str:TStringList);
begin
  :
  str.append(format('Hajo...%d',[i]));
  :
end;


begin
  :
  DoSomethingWithTheList(TStringList.create);
  :
end;

Vielleicht noch als Tipp:

Da ich auch FastMM verwende, schalte ich den während der Entwicklung in den FullDebugMode (da sind
auch die Leaks mit dabei). Allerdings bekom ich halt auch ein Log-File, wo etwas mehr Infos drinn
stehen :)

[sakura]

Wie bereits geschrieben wurde, suche zuerst nach den von Dir direkt genannten Elementen, welche nicht frei gegeben wurden, in diesem Fall die TDev... Objekte.

Anschließend, sollten noch Memory Leaks auftreten, schaust Du, wo die im Report genannten Klassen von Dir verwendet werden und fängst and deren Lebenszyklus zu überprüfen.

Ein normales Delphi-Programm hat erst einmal keine Speicherlöcher.

Achtung: wenn Du viel mit Interfaces arbeitest und durch den Debugger gehst, gibt es eigentlich immer Speicherlöcher, welche durch den Debugger (Watches, etc.) entstehen. Dieser Bericht ist ohne Eingreifen (Anhalten) durch den Debugger eigentlich immer korrekt, aber wenn Du das Programm im Debugger angehalten hast, ignoriere den lieber, bevor Du Geister jagst.

...:cat:...

[haentschman]

Moin...:P

Zitat:

ich habe mal zum Spaß und aus Neugier System.ReportMemoryLeaksOnShutdown := True; gesetzt.

...das ist schon der erste Fehler. :P Im Nachhinein ist das schlecht herauszufinden. :? Wenn du es immer anhast, dann wirst du immer "gewarnt" wenn du etwas vergessen hast. Dann ist der Bereich wo du schauen mußt übersichtlicher...:P

Ansonsten gelten die Tipps meiner Vorgänger. :thumb:

[hoika]

Hallo,
setze bei den Link-Optionen auch TD32 und ext. Debug-Symbole.
Dann zeigt er Dir die Unit und die Zeile der Erzeugung des Leaks.

In Dienme Fall erzeugst du wohl ein dynamisch ein Grid (TDevGrid) und gibst es nicht mehr frei.
Das reißt dann die anderen Leaks auf.

[Der schöne Günther]

Der von Embarcadero mitgelieferte FastMM4 kann das doch gar nicht, oder? Wenn du den "richtigen" von https://github.com/pleriche/FastMM4 nimmst kannst du dir in ebendiesem Logfile genau anzeigen lassen:

"He, da wurde ein Objekt vom Typ TStringList nicht freigegeben. Als es erstellt wurde war der Callstack:
TForm1.erstelleKram(..) - Zeiel 5
TForm1.Button1Click(..) - Zeile 3
[...]
Application.Run()"

[sakura]

Zitat:

Zitat von hoika (Beitrag 1353337)

setze bei den Link-Optionen auch TD32 und ext. Debug-Symbole.
Dann zeigt er Dir die Unit und die Zeile der Erzeugung des Leaks.

Zumindest im Standard-Memorymanager von Delphi gibt das keine weiteren Informationen.

@Sherlock:
Hier mal ein Beispiel für lediglich ein Objekt, welches nicht freigegeben wurde und die dadurch entstandenen Speicherlöcher. Manchmal kann ganz wenig zu sehr viel führen.

Code:

An unexpected memory leak has occurred. The unexpected small block leaks are:

1 - 12 bytes: TMoveArrayManager<OCTAX.Biometrics.IOctaxBiometricsRegisteredUser> x 1, TMoveArrayManager<OCTAX.Biometrics.IOctaxBiometricsDevice> x 1, TMoveArrayManager<System.NativeUInt> x 2, TMoveArrayManager<OCTAX.Common.Hardware.IOctaxHardware> x 1, Unknown x 5
21 - 28 bytes: TOctaxBiometricsDatastoreMemory x 1, TOctaxBiometricsAnalyzer x 6, TOctaxProvider x 8
29 - 36 bytes: TCriticalSection x 5, TDigitalPersonaQuality x 1
37 - 44 bytes: TDigitalPersonaFingerJetAnalyzer x 1
45 - 52 bytes: TList<System.TMethod> x 5
53 - 60 bytes: TCollectionChangedEventImpl<OCTAX.Biometrics.IOctaxBiometricsDevice> x 1, TCollectionChangedEventImpl<OCTAX.Biometrics.IOctaxBiometricsRegisteredUser> x 1, TCollectionChangedEventImpl<System.NativeUInt> x 2, TCollectionChangedEventImpl<OCTAX.Common.Hardware.IOctaxHardware> x 1
61 - 68 bytes: TOctaxBiometricsManager x 1, UnicodeString x 6
69 - 76 bytes: TList<OCTAX.Biometrics.IOctaxBiometricsRegisteredUser> x 1, TList<OCTAX.Biometrics.IOctaxBiometricsDevice> x 1, TList<System.NativeUInt> x 2, UnicodeString x 1
77 - 84 bytes: TOctaxHardwareManager x 1, UnicodeString x 1
117 - 124 bytes: TDigitalPersonaFingerJet x 1
189 - 204 bytes: UnicodeString x 8

...:cat:...

P.S.: Ich hatte zur Demonstration des Ergebnisses einfach mal sichergestellt, dass EIN Objekt nicht freigegeben wurde. ;)

[Sherlock]

Ahaaa, Vielen Dank für die Hinweise! Ich hatte zwei Threads die nicht immer sauber beendet wurden. Das habe ich immerhin schon eliminieren können. Jetzt muss ich mir mal das volle FastMM installieren. In dem Zusammenmhang: Wo stelle ich das mit dem TD32 ein? Externe Symbole habe ich gefunden, aber TD32... seh ich nicht. Berlin.

Sherlock

[Stevie]

Zur genaueren Analyse von Memoryleaks empfehle ich LeakCheck. Mit dem usage Graph kann man dann bei einem umfangreicheren Leak leichter das Rootobjekt identifizieren.

Zitat:

Zitat von Sherlock (Beitrag 1353367)

Wo stelle ich das mit dem TD32 ein? Externe Symbole habe ich gefunden, aber TD32... seh ich nicht. Berlin

Linking->Debug information auf True setzen

[Sherlock]

Danke für den Tipp. Ich werde dann mal auch das Delphi-LeakCheck testen. Wie war die Kirmes? ;)

Erster Abtörner...genau wie beim FastMM4 steht nicht, was man in die Bibliothekspfade oder Suchpfade eintragen soll. Das ist...so was von Grundlage, ohne läuft gar nichts. Schade eigentlich, denn ansonsten sieht das schon viel professioneller und aufgeräumter als FastMM4 aus.

Sherlock

[sh17]

Zitat:

Zitat von Stevie (Beitrag 1353368)

Zur genaueren Analyse von Memoryleaks empfehle ich LeakCheck. Mit dem usage Graph kann man dann bei einem umfangreicheren Leak leichter das Rootobjekt identifizieren.

Ist das als Ersatz für FastMM ?

[Sherlock]

Stevie: Was muss ich einstellen, damit das wie FastMM4 eine Ausgabedatei erstellt? Im Moment ist das alles etwas sehr unübersichtlich. Nachdem ich LeakCheck in die öffentlichen Dokumente geklont habe und im Delphi die Bibliothekspfade für Win32, Win64 und OSX um diesen Pfad ergänzt habe steht jetzt in der DPR meines Projekts folgendes:

Delphi-Quellcode:

uses
  //FastMM4,
  LeakCheck,
  System.StartUpCopy,
  LeakCheck.Utils,
  FMX.Forms,

//etc.

begin
  if DebugHook <> 0 then
    System.ReportMemoryLeaksOnShutdown := True;
  Application.Initialize;
//und so weiter

end;

Ich finde in der LeakCheck.Configuration.inc keinen Schalter zum Erzeugen eines Reports, also starte ich einfach mal mein Programm spiele ein wenig damit und beende es, am Ende erscheint ein riesiger Dialog, der unübersichtlicher ist als der von FastMM4 (Scrollboxen oder Memos mit Scrollbars darf man in Dialogen verwenden, oder?). Wo mache ich LeakTest klar, daß der Dialog sinnlos ist, und bitte eine Datei geschrieben werden sollte?

Sherlock

[TiGü]

Zitat:

Zitat von Sherlock (Beitrag 1353373)

Wo mache ich LeakTest klar, daß der Dialog sinnlos ist, und bitte eine Datei geschrieben werden sollte?

Steht doch in der Beschreibung:

Zitat:

It plugs into default ReportMemoryLeaksOnShutdown
You can use ReportMemoryLeaksOnShutdown on any platforms.

The output varies across platforms:
On Windows message box containing the leaks is shown, this behavior can be changed by defining NO_MESSAGEBOX conditional in which case the output will be sent into the IDE Event log (by OutputDebugString)

[Sherlock]

Das habe ich auch gesehen, aber: Der IDE Eventlog ist nun wirklich nicht so übersichtlich wie eine simple Datei.

Edith sagt: abgesehen davon funktioniert es auch einfach nicht. Ich habe NO_MESSAGEBOX in den Projektoptionen gesetzt, und auch direkt in der DPR, ohne spürbare Änderung. Die Messagebox kommt weiterhin. Ich lass die Sache jetzt noch bis Montag köcheln, und setze mich mit frischer Geduld wieder für ein bis zwei Stündchen dran. :)

Sherlock

[TiGü]

Wenn du keine Option dafür findest: Aus dem IDE Eventlog kannst du auch den Eintrag selektieren, kopieren und in eine Datei einfügen.

[Stevie]

Zitat:

Zitat von sh17 (Beitrag 1353370)

Zitat:

Zitat von Stevie (Beitrag 1353368)

Zur genaueren Analyse von Memoryleaks empfehle ich LeakCheck. Mit dem usage Graph kann man dann bei einem umfangreicheren Leak leichter das Rootobjekt identifizieren.

Ist das als Ersatz für FastMM ?

Nein, LeakCheck ist einzig fürs MemoryLeak finden geschrieben und keinesfalls als sonstiger Ersatz für FastMM.

[Sherlock]

Sodele, hab mich das Wochenende über entspannt, und nach weiterem kurzem und erfolglosem Kampf mich gegen LeakCheck entschieden. Also wieder zu FastMM4. Die drei MemoryLeaks, die ich selbst verschuldet habe, sind ausgemerzt. Jetzt bleiben "nur" noch runde 240 Leaks. Problematisch bei denen ist folgendes:

Zitat:

A memory block has been leaked. The size is: 52

This block was allocated by thread 0x1E5C, and the stack trace (return addresses) at the time was:
407405 [System.pas][System][@ReallocMem$qqrrpvi][4806]
40CC0F [System.pas][System][DynArraySetLength$qqrrpvpvipi][34250]
40CD52 [System.pas][System][@DynArraySetLength$qqrv][34348]
40F0CC [System.pas][System][TInstBucket.AddInstItem$qqrip16System.TInstItem][36911]
407362 [System.pas][System][AllocMem$qqri][4557]
408DD2 [System.pas][System][TMonitor.Create$qqrv][18091]
40F567 [System.pas][System][TInstHashMap.RegisterWeakRef$qqrpvt1][37124]
40F857 [System.pas][System][RegisterWeakRef$qqrpvxp14System.TObject][37215]
40F8FA [System.pas][System][@IntfWeakCopy$qqrr44System.%DelphiInterface$17Syst em.IInterface%44System.%DelphiInterface$17System.I Interface%][37314]
82079F [FMX.Controls.pas][FMX.ListBox][Controls.%TContentInflater__1$p24Fmx.Listbox.TList BoxItem%.$bctr$qqrx91System.%DelphiInterface$64Fmx .Controls.%IInflatableContent__1$p24Fmx.Listbox.TL istBoxItem%%][8558]
814666 [FMX.ListBox.pas][FMX.ListBox][Listbox.TCustomListBox.$bctr$qqrp25System.Classes. TComponent][1680]

The block is currently used for an object of class: Unknown

Weder sehe ich, welche "meiner" Units daß verbockt hat, noch kann ich überhaupt erkennen, um welche Klasse es hier geht.

Sherlock

[Der schöne Günther]

Zitat:

Zitat von Sherlock (Beitrag 1353598)

40F567 [System.pas][System][TInstHashMap.RegisterWeakRef$qqrpvt1][37124]

Ganz dumme Frage: 10 Seattle oder 10.1 Berlin? 10 Seattle hatte auf Windows doch noch keine schwachen Referenzen, das wird dann wohl einfach ein Leak in der RTL/FMX/VCL sein (oder?).

[Sherlock]

Berlin mit Update 1... und es ist FMX. *Seufz*

Ich werde mal schauen, ob die Leaks mehr werden oder ob die Zahl konstant bleibt. Das bekomme ich nach starten, einmal alles klicken und schließen:

Zitat:

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

37 - 52 bytes: Unknown x 22
53 - 68 bytes: Unknown x 209
245 - 276 bytes: Unknown x 11

Alle Details dazu sehen bis auf Adressen und ähnlichen "Kleinkram" nahezu identisch aus... Der Löwenanteil macht aber ein Leak im Zusammenhang mit Listboxen aus, und die, also ausgerechnet die, verwende ich nur statisch. Da ist nix zu Laufzeit hinzugefügtes bei :(

Sherlock

[Der schöne Günther]

Ja, ich sehe es grade. 10.1 Berlin mit Update 1 und einfach mal eine FMX-Combobox aufs Formular gepackt. Dann habe ich auch 240 Leaks. :shock:

PS: Das hat aber nichts wirklich mit FMX direkt zu tun. Bei meinem Test fängt FastMM schon an Leaks zu "finden" bevor der finalization-Block von System.pas läuft - Das ist natürlich unfair und nicht wahr. Wie bekommt man FastMM nochmal dazu das nicht zu tun? Ist das die Option "Never uninstall"?

[Sherlock]

Keine Ahnung, was mich aber am meisten nervt ist, mit FastMM4 bekomme ich IMMER eine Schutzverletzung am Programmende, ohne kommt nix. :(

Sherlock

[Der schöne Günther]

Du kannst in FastMM einstellen dass er eine AV werfen soll wenn auf eine bereits freigegebene Instanz zugegriffen wird. Das ist es nicht?

PS: Einstellen der FastMM-Parameter macht mit diesem Tool hier gleich viel mehr Spaß:
http://jedqc.blogspot.de/2007/07/new...interface.html

[Bambini]

Zitat:

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

Ja, ich sehe es grade. 10.1 Berlin mit Update 1 und einfach mal eine FMX-Combobox aufs Formular gepackt. Dann habe ich auch 240 Leaks. :shock:

Bei XE8 unter Mac OS waren es tausende für eine nackte TForm. Das FastMM4 Reportfile ist da schlappe 16MB groß.
Der QC Eintrag ist immer noch offen, aber ich glaube das ist mit Berlin schon besser geworden.
https://quality.embarcadero.com/browse/RSP-10397

[Der schöne Günther]

Aah, hier ist was ich meinte bzgl. der schwachen Referenzen, System.pas, all das:

http://www.delphipraxis.net/189654-f...es-delphi.html

[TiGü]

Zitat:

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

Aah, hier ist was ich meinte bzgl. der schwachen Referenzen, System.pas, all das:

http://www.delphipraxis.net/189654-f...es-delphi.html

Und, haste mit NeverUninstall immer noch die vielen Leaks?

[Der schöne Günther]

Um ehrlich zu sein schon :?

[Stevie]

Das hatten wir doch neulich erst.

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

Edit: nvm, das war ja schon verlinkt

[Der schöne Günther]

Das behebt nur die AV am Schluss. Die False Positives bei den Leaks nicht.

[Stevie]

Zitat:

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

Das behebt nur die AV am Schluss. Die False Positives bei den Leaks nicht.

Das sind keine false positives, sondern Leaks die größtenteils statisch sind, aber nicht explicit freigeräumt werden.
Wenn die Anwendung endet, geht der Speicher zurück an Windows.

Leider sehr unsauberer Stil, der in der letzten halben Dekade gerade im FMX Bereich weit verbreitet praktiziert wurde. :(

LeakCheck.pas rein,

Delphi-Quellcode:

TLeakCheck.IgnoredLeakTypes := [tkUnknown];

noch gesetzt und ab gehts.
Klar, damit werden alle leaks vom Typ unknown ausgefiltert, das ist meist jeglicher Speicher, der direkt mit GetMem angefordert wurde und dann weiter verarbeitet wird.
Das ist aber meist in einer UI Anwendung nicht der Speicher, den man selbst leakt.

In der blanken FMX Anwendung, mit TComboBox drauf, die normalerweise 200 und nen paar unknown leaks gibt, ist dann Ruhe.

[Der schöne Günther]

Gut das mal vom Profi zu hören, wir hätten noch ewig weiterraten können :roteyes:

[Sherlock]

:thumb:
Danke, Stevie!

Dann hatte ich ja fast alles richtig gemacht in meiner Anwendung :)

Sherlock

[Der schöne Günther]

Jetzt würde ich aber noch gern die "Unknown"-Sache besser verstehen. Warum ist es "Unknown"? Weil einer manuell einen Speicherblock angefordert und mit irgendetwas gefüllt hat? Kann ich, ohne so etwas, in meiner Anwendung auch "Unknown"-Belegungen erzeugen?

[Zacherl]

Zitat:

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

Jetzt würde ich aber noch gern die "Unknown"-Sache besser verstehen. Warum ist es "Unknown"? Weil einer manuell einen Speicherblock angefordert und mit irgendetwas gefüllt hat? Kann ich, ohne so etwas, in meiner Anwendung auch "Unknown"-Belegungen erzeugen?

"Unknown" ist für FastMM4 alles, was du manuell mit

Delphi-Quellcode:

GetMem

und ich glaube auch per

Delphi-Quellcode:

SetLength

(im Falle von dyn. Arrays) alloziierst.

[Stevie]

Generell ist alles über GetMem, AllocMem oder ReallocMem allokiert (siehe z.B.

Delphi-Quellcode:

TObject.NewInstance

), der Memory Manager kennt nix anderes (siehe

Delphi-Quellcode:

System.TMemoryManagerEx

).
Allerdings werden einige durchaus aufwändige Analysen des Speicherblocks durchgeführt, um recht zuverlässig festzustellen, obs ein Objekt oder string ist, alles andere is unknown.
Solcher Speicher hat nämlich ein gewisses "Aussehen". Siehe dazu

Delphi-Quellcode:

DetectClassInstance

und

Delphi-Quellcode:

DetectStringData

in

Delphi-Quellcode:

FastMM4.pas