Was mache ich mit der MemoryLeak Ausgabe?

[Sherlock]

Hi,
ich habe mal zum Spaß und aus Neugier 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
---------------------------

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 von Sherlock:

Hi,
ich habe mal zum Spaß und aus Neugier System.ReportMemoryLeaksOnShutdown := True; gesetzt. Die Ausgabe erscheint mir jetzt nicht so wirklich hilfreich zu sein.


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.

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.

......

[haentschman]

Moin...

Zitat:

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

...das ist schon der erste Fehler. 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...

Ansonsten gelten die Tipps meiner Vorgänger.

[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 von hoika:

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

......

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 von Sherlock:

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