Memory Leak: Ursache finden

[sx2008]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1203892)

Ich bin nur ein wenig enttäuscht von MadExcept, so dass es mir wirklich gar kein Hinweis geben konnte. Ist technisch aber sicher auch nicht ganz einfach.

Je mehr man auf Klassen setzt, umso leichter wird die Fehlersuche.
Man kann z.B. dynamischee Arrays direkt in der Anwendung, der "Businesslogik", benützen.
Oder man kapselt das Array innerhalb einer Klasse und lässt nur einen kontrollierten Zugriff über die Methoden der Klasse zu.
Insbeondere sollte man Resourcen (Speicher ist auch eine Resource) immer unter die Kontrolle einer Klasse stellen.
Das heisst dann konkret, dass AllocMem und FreeMem nur im geschützten Kontext einer Klasse aufgerufen werden.
Dann testet man diese Klasse in einer isolierten Umgebung (aka Testprogramm) und kann so sicherstellen, dass die Klasse in sich keine Speicher- oder Resourcenlecks hat.

Findet man später in der Anwendung ein Speicherleck ist die Wahrscheinlichkeit höher, dass man den Klassennamen angezeigt bekommt und so gezielt suchen kann.

Manchmal bekommt man nur allgemeine Klassennamen gemeldet (z.B. TStringList x 14), dann kann man auch von TStringList abgeleitete Klassen einsetzen.
Kleines Beispiel dazu:

Delphi-Quellcode:

// Klasse zum Laden von Daten aus einer Datei
// wird zum Datenimport verwendet
// die Datei darf nicht leer sein
TImportStringList = class(TStringList)
public
  procedure LoadFromFile(const FileName: string); override;
end;

procedure TImportStringList.LoadFromFile(const FileName: string);
begin
   inherited;
   if count = 0 then
      raise EBadImportFile.CreateFmt('Datei %s ist leer', [FileName]);
end;

So schlägt man zwei Fliegen mit einer Klappe.
Man kann kleine Teile der Funktionalität an TImportStringList übertragen (prüfen ob Datei leer ist) und ausserdem bekommt man bei einem Speicherleck gezielte Info wo zu suchen ist.

Die ganzen Punkte oben gelten speziell für sehr grosse Anwendungen mit Hunderten von Units.
Bei kleinen Anwendungen braucht man nicht so viel Aufwand zu treiben.

[BerlinärBär]

Hallo zusammen,

falls sich noch jemand für die Erklärung interessiert:
Es ist wirklich das 'FillChar', aber nur, weil es falsch angewandt wurde:
Statt 'FillChar( fHfgkFarbe, SizeOf( fHfgkFarbe ), 0)'
muss es 'FillChar( fHfgkFarbe[0], Length(fHfgkFarbe)*SizeOf(ein element davon), 0)'
heißen. Die obere Zeile leert nur die Feldvariable, aber der damit verbundene Speicherblock mit dem eigentlichen Feldinhalt ist ab dann für den Delphi-Speichermanager unsichtbar.

Gruß vom Bären!

[Blup]

@BerlinärBär Die Ursache für das Speicherleck wurde schon in #20 genannt.

[BerlinärBär]

@Blup: Ups, war wohl selektives Lesen...