ReportMemoryLeaksOnShutdown:= True – Deutung der Speicherleck-Meldung

[generic]

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

[Andreas13]

@Generic
Danke, Bernd!
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.

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

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,
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!
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…

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 !

Viele Grüße
Andreas