ReportMemoryLeaksOnShutdown:= True – Deutung der Speicherleck-Meldung

[Andreas13]

Hallo Community,
wegen einer Verständnisfrage wende ich mich diesmal an Euch:

Ein mysteriöser Speicherleck (tritt merkwürdigerweise nur auf, wenn ich einige Vektoren und Matrizen mit der Länge n = 4 bzw. 4 x 4 dimensioniere, nicht jedoch, wenn n = 6 oder höher ist. :wall:) liefert die Meldung (s. Bild), wenn:

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown:= True;

.
Auch madExcept hilft mir leider nicht beim Finden meines Fehlers: Seine Meldungen kann ich noch weniger deuten und auswerten.

Daher die Frage:
Was bedeuten die Zahlen in der Fehlermeldung konkret?

- Habe ich Speicherlecks in Höhe von 61 bis 68 Bytes insgesamt 24-mal?
- Oder etwas ganz anderes?

Ich möchte eigentlich wissen, um wieviel Bytes es sich insgesamt handelt, um für das Projekt eventuell eine "vorläufige Bagatellgrenze" zu definieren, da ich nicht noch mehr Zeit mit der Speicherleck-Suche verplempern möchte... :oops:

Danke & viele Grüße
Andreas

[Rolf Frei]

Ja zumindest ich habe das auch immer so interperetiert. Du hast 24 nicht freigegebene Memoryblöcke mit einer Grösse von 61-68 Bytes. Für die genauere Fehlersuche nutze ich dann die Vollverison des FastMM4 und habe da diverse Debug Optionen aktiviert, mit dene alles viel detailierter in ein Logfile geschrieben wird.

Die Vollversion findest du hier und beachte dabei insbesondere die Datei FastMM4Options.inc: https://github.com/pleriche/FastMM4

[Delphi.Narium]

Als Ergänzung dazu:

Schau mal bitte in die FastMM4Options.inc, sie enthält diverse Schalter, die bei der Fehlersuche durchaus hilfreich sein können.

Da wäre u. a.

{$define FullDebugMode}

und desweiteren

{$define LogErrorsToFile}

Damit bekommst Du etwas ausführlichere Informationen in eine Datei geschrieben.

Ein Auszug aus 'nem Programm von mir:

Code:

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

This block was allocated by thread 0x6E0, and the stack trace (return addresses) at the time was:
402EAC [IdCharsets][IdCharsets][@GetMem]
4045EF [IdGlobalProtocols][IdGlobalProtocols][QuoteSpecials]
40498A [IdHeaderCoder2022JP][IdHeaderCoder2022JP][@ClassCreate]
4A59D6 [..\Indy10\Lib\Core\IdThreadSafe.pas][IdThreadSafe][TIdThreadSafe.Create][251]
49750B [..\Indy10\Lib\Protocols\IdAuthentication.pas][IdAuthentication][RegisterAuthenticationMethod][157]
4A5B65 [..\Indy10\Lib\Core\IdThread.pas][IdThread][IdThread][730]
4050EB [IdSSLOpenSSLHeaders][IdSSLOpenSSLHeaders][EVP_PKEY_meth_free]
405153 [IdSSLOpenSSLHeaders][IdSSLOpenSSLHeaders][EVP_PKEY_decrypt]
407CD7 [SysInit][SysInit][..]
683A14 [lw:\Verzeichnis\Programmname.dpr][Programmname][Programmname][142]
7C92B084 [Unknown function at RtlUnicodeStringToInteger]

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

The allocation number is: 297

Current memory dump of 256 bytes starting at pointer address 7FAA4750:
(* hier folgt dann ein Hex-Dump *)

Die Zahlen rechts in den eckigen Klammen dürften die Zeilenzahl in der Quelltextdatei sein, an der das von FastMM festgestellte Speicherleck seinen Ursprung hat.

Bei dem Progamm handelt es sich um 'ne olle Klamotte mit Delphi 7 und Indy10 erstellt.

[Andreas13]

Hallo,
vielen Dank für Eure Tipps! :thumb: :angel:
Ich glaube mit FastMM4 bereits eine heiße Spur gefunden zu haben.
Viele Grüße
Andreas

[jaenicke]

An der Stelle auch für spätere Leser noch ein Hinweis:
Zum Beispiel bei anonymen Methoden ist es manchmal nicht möglich ein (sehr kleines) Speicherleck zu verhindern. In solch einem Fall kannst du mit RegisterExpectedMemoryLeak das Speicherleck ausblenden, so dass es nicht mehr in der Liste auftaucht.

[Andreas13]

Danke, Sebastian! :thumb:
Es stellt sich für mich die neue Frage, ob FastMM4 alleine genügt und ob ich daher madExcept deinstallieren sollte? Dessen umfangreiche "leak reports" konnte ich leider weder deuten, noch haben sie mich auf eine heiße Spur gebracht.

Grüße, Andreas

[freimatz]

Ich nehme immer madExcept, da bekomme gleich einen "schönen" Callstack.
Was davon kannst Du nicht deuten?

[taveuni]

Zitat:

Zitat von jaenicke (Beitrag 1508430)

(..)Zum Beispiel bei anonymen Methoden ist es manchmal nicht möglich ein (sehr kleines) Speicherleck zu verhindern.(..)

Kann ich mir grad nicht vorstellen. Was wäre da ein Beispiel?

[Andreas13]

@Freimatz
Hallo,
FastMM4 sagte mir direkt, welche Routine den Speicherleck verursacht hat. Der viele Seiten lange Callstack von madExcept war für mich leider eher verwirrend. Auch war dort kein konkreter Hinweis für die eigentliche Ursache, oder ich habe diese vor lauter Bäumen nicht sehen können... :oops:

Die zwei madExcept Uralt-Videos auf der Homepage passen überhaupt nicht zur jetzigen Version und sind leider überhaupt keine Hilfe. Auch vermisse ich eine Art Tutorium für madExcept-Anfänger.

Grüße, Andreas

[Rolf Frei]

Ich habe vor langer Zeit auch mal MadExcept genutzt, aber heute nutze ich den nicht mehr. Zur Fehlersuche reicht mir FastMM4 völlig aus. Das fertige Programm kompiliere ich dann mit dem Delphi internen FastMM4.

[haentschman]

Hallöle...8-)

Zitat:

Zur Fehlersuche reicht mir FastMM4 völlig aus

...einen Callstack per Mail geschickt vom User ist nicht notwendig? :gruebel:

[Rolf Frei]

Nein. Bei mir teste ich das Programm, nicht der Kunde. Wenn da mal was ist, sind das übersehene Kleinigkeiten, die mit einer genauen Anleitung wie es zum Fehler kommt, immer schnell behoben sind. Habe all die Jahre, seit denen ich mit Delphi programmiere (seit Delphi 1), noch nie einen Callstack benötigt.

Memoryleaks gibt es generell keine bei dem Kunden, dafür sorge ich schon zur Programmierzeit mit sauberem Coden (immer abgesichertes Erstellen und Freigeben von Objekten, etc.). Eine Anwendung die Memoryleaks produziert, wird garnicht erst an Kunden ausgeliefert, sondern vorher gründlich getestet und bereinigt.

[himitsu]

Nutzt du kein INDY/DataSnap? Da sind Speicherlecks drin. :stupid:

Aber die bekam man nicht weg, also wurden sie einfach auf die Blacklist (RegisterExpectedMemoryLeak) gesetzt, damit sie niemanden stören.

[Rolf Frei]

Nein nutze weder DataSnap noch Indy. Für beides nutze ich 3rd Party Software.

Es geht ja nicht um die Leaks die man wissentlich drin hat und vom MM ignoriert werden. Es geht um eigene Leaks, die man durch unsauberes programmieren verursacht. Und für sonstige Fehler wie AV's bekomme ich vom Kunden genaue Anweisungen und kann das in der Regel problemlos reproduzieren und beheben.

[generic]

In diesem Video erkläre ich auch noch die eine oder andere Funktion vom FastMM:
https://youtu.be/o0yZgQoV8MA

[Andreas13]

@Generic
Danke, Bernd! :thumb:
Gruß, Andreas

[jaenicke]

Erwähnenswert ist auch unter "Demos\Usage Tracker" das Fenster mit detaillierten Speicherinformationen, das man auch in einer eigenen Anwendung anzeigen kann.

[Andreas13]

Hallo again,
vom ursprünglichen Speicherleck (24 x 68 Bytes) konnte ich mit FastMM4 auf Anhieb 21 Fragmente beheben. Die restlichen 3 x 68 Bytes sind aber sehr hartnäckig:
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer): 53 - 68 bytes: Unknown x 3
und ich kann sie leider immer noch nicht genau aufspüren. :wall:

Mir kommt bereits die erste (s. Bild-1.jpg) der drei Meldungen etwas merkwürdig vor:
1):
415802 [FastMM4.pas][FastMM4][CalculateHeaderCheckSum$qqrp29Fastmm4.TFullDebugBl ockHeader][9143]

Wieso erscheint auch FastMM4 in dieser Liste? FastMM4 steht bei mir in meiner uses-Liste an der ersten Stelle:

Delphi-Quellcode:

uses
  {$IfDef DEBUG}
    FastMM4,
  {$EndIf }
  System.SysUtils,
  Winapi.MMSystem,
  PDBiA_Type,
  PDBiA_Mathe

Hat etwa auch FastMM4 einen "eigenen" Speicherleck?

2):
5D3A35 [MP_Real.pas][mp_real][mpf_initp3$qqrr17Mp_types.mp_floatt1t1i][3756]
MP_Real.pas steht gar nicht in der uses-Liste des Projektes, sondern in der von PDBiA_Mathe.pas.

Im ersten der drei Abschnitte der Fehlerberichte fehlt die Zeile
5FDC1D [PDBiA_Mathe.pas][PDBiA_Mathe][MPAF_Init$qqrr17Mp_types.mp_floatt1t1i][19140], in den darauffolgenden zwei ist sie bereits (korrekterweise) vorhanden (s. Bild-2.jpg). Den „memory dump” habe ich hier weggelassen: Ich kann damit leider gar nichts anfangen, genau so wie mit der allocation number.

Allerdings bemängelt auch madExcept 3 gleichgroße Speicherlecks, nur mit einer viel längeren Liste von Procedure-Aufrufen.

3):
Merkwürdig ist auch, daß in der Übersichtsmeldung stets von "53 - 68 bytes" die Rede ist, im Detail-Bericht es aber immer genau 68 Bytes sind. Was stimmt jetzt? (Die vermutliche Speicherleck-verursachende Routine mpf_initp3(..) belegt eigentlich nur 3-mal 24 = 72 Bytes.)

Vielleicht hat jemand von Euch noch eine weitere rettende Idee?

Danke & Grüße
Andreas

[himitsu]

Zitat:

Merkwürdig ist auch, daß in der Übersichtsmeldung stets von "53 - 68 bytes" die

Das ist nicht merkwürdig.

Zur Optimierung gibt es im FastMM mehrere SmallBlock-Verwaltungen für kleine Speicherbereiche.
In dieser BlockGruppe landen Speicheranforderungen von 53 bis 68 Bytes. (größere und kleinere Anforderungen laden in anderen BlockGruppen)
Und dann gibt es auch noch größere MediumBlocks (aufwändiger dynamisch unterteilt) und ganz große LargeBlocks, welche nicht geteilt sind.

stell dir es so vor:
FastMM holt bei den SmallBlocks immer 64KB vom Windows, teilt das in feste Blöcke auf und gibt diese Kleinteile an dein Programm weiter, da Windows nicht ganz schnell ist und im System der Speicher auch nicht so kleinteilig verwaltet wird. ()
ab Zeile 2000 > https://github.com/pleriche/FastMM4/...er/FastMM4.pas

Die "Kurzübersicht" schaut nur schnell darauf, in welchem SmallBlock dieser Speicher/Pointer liegt, also hier in einem SmallBlock für 53-68 Bytes.
Mit zusätzlichen Debuginfos wird dann auch für jeden einzelnen Teil explizit gespeichert, wie groß das genau war und von wo es angefordert wurde (Stacktrace).


Kann gut sein, dass im mp_arith von Gammatester ein paar Fehlerchen drin sind.
Nur er (Wolfgang Ehrhardt) wird es nicht mehr beheben können.

[Andreas13]

Danke für die Klarstellung der Größe der Block-Gruppen, Himitsu.

Zitat:

Zitat von himitsu (Beitrag 1508583)

Kann gut sein, dass im mp_arith von Gammatester ein paar Fehlerchen drin sind. Nur er (Wolfgang Ehrhardt) wird es nicht mehr beheben können.

Leider, :cry: :cry:
3 – 4 kleinere Fehler in einigen seiner Bibliotheken habe ich bereits behoben. Aber diesmal bin ich ratlos, zumal der Speicherleck selbst von den Testdaten abzuhängen scheint (s. # 1).
Gruß,
Andreas

[Andreas13]

Habe den Fehler gefunden! :-D
Eine MPAF-Variable (Multi Precision Arithmetic Float) hatte ich versehentlich zweimal initialisiert: Einmal "normal", und ein weiteres Mal bedingungsabhängig mit einer höheren Bit-Präzision… :wall:

Allerdings habe ich (erneut) eine für mich fatale Beobachtung gemacht: FastMM4 korrumpiert mehrere Inhalte meiner zahlreichen MPAF-Variablen. Aus numerischen Werten werden manchmal string-ähnliche Hieroglyphen und die Berechnung stürzt im besten Fall ab, im schlimmeren Fall sind "nur" die Ergebnisse völlig falsch. Deshalb hatte ich FastMM4 bereits 2019 aus meinen Projekten "verbannt", wie ich es gerade feststellen konnte. :(

Mein Fazit:
Geholfen hat mir in diesem letzten mühseligen Schritt der Speicherleck-Suche leider weder FastMM4 noch madExcept so richtig.

Danke für Eure Hilfe & Beiträge ! :thumb:

Viele Grüße
Andreas

[himitsu]

Eigentlich sollte das nicht passieren.

Könnte eher sein, dass diese Komponente außerhalb/hinter den reservierten Speicher schreibt (Bufferoverrun)
und es sich dabei mit FastMM in die Quere kommt, welches davon ausgeht, dass jeder nur in seinen Speicher schreibt. :angle:

[mjustin]

Zitat:

Zitat von Andreas13 (Beitrag 1508594)

Geholfen hat mir in diesem letzten mühseligen Schritt der Speicherleck-Suche leider weder FastMM4 noch madExcept so richtig.

Vielleicht hat sich das inzwischen gebessert, da es eine neue Version gibt: FastMM5

https://github.com/pleriche/FastMM5

Delphi XE3 and later

[Andreas13]

Hallo,

Zitat:

Zitat von mjustin (Beitrag 1508599)

Vielleicht hat sich das inzwischen gebessert, da es eine neue Version gibt: FastMM5 https://github.com/pleriche/FastMM5

Lieder ist FastMM5 auch nicht besser, s. Beispiel:

Code:

  ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥  
  x = ?ÏÑ♥62543041E+199999903
  t =  ?ÏÑ♥
  a[1] =  ?ÏÑ♥3997329E+199999951
  a[2] = ?ÏÑ♥23997329E+199999951
  a[3] =  ?ÏÑ♥3983403E+199999904

Zitat:

Zitat von himitsu (Beitrag 1508597)

Eigentlich sollte das nicht passieren.
Könnte eher sein, dass diese Komponente außerhalb/hinter den reservierten Speicher schreibt (Bufferoverrun) und es sich dabei mit FastMM in die Quere kommt, welches davon ausgeht, dass jeder nur in seinen Speicher schreibt.

Unser Gammatester war ein wahrer Pointer-Akrobat und trickst den Speichermanager von FastMM auch noch posthum aus... :)

Grüße
Andreas