ReportMemoryLeaksOnShutdown:= True – Deutung der Speicherleck-Meldung

[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