Memory Leak: Ursache finden

[sx2008]

Ein kleiner Tipp: durchsuche den gesamten Sourcecode nach "destructor Destroy; "; wenn irgendwo der Zusatz "override; " fehlt, dann ist das ein potentielles Speicherleck.

Zusätzlich kann man noch nach "destructor T" suchen und prüfen ob in jedem Destruktor auch das inherrited aufgerufen wurde.

[Jazzman_Marburg]

Zitat von sx2008:

Ein kleiner Tipp: durchsuche den gesamten Sourcecode nach "destructor Destroy; "; wenn irgendwo der Zusatz "override; " fehlt, dann ist das ein potentielles Speicherleck.

Zusätzlich kann man noch nach "destructor T" suchen und prüfen ob in jedem Destruktor auch das inherrited aufgerufen wurde.

Ein sehr guter Tipp -- leider kein Destructor ohne override, und in jedem Destructor ist stets ein "inherited Destroy;"
Ich dachte schon, dass muß es sein... Dennoch ein guter Tipp!

Zitat von Union:

[...] Warum? MadExcept arbeitet ja nicht nach dem Zufallsprinzip. Also mal gucken: Wie ist fHfgkFarbe definiert? Ist es eine property, eine private oder was sonst? Wird das vielleicht irgendwo vorher auf nil gesetzt?

Diesen Hinweis verstehe ich nicht, ich sagte ja, bei fHfgkFarbe handelt es sich um ein Array of Integer -- und ja, es ist ein private Klassenvariable. Ein Nil ist nirgends zu finden.

Zitat von Aphton:

Man kann zuerst einmal auch manuell den Code durchscannen, sofern es sich noch um kein allzu umfangreiches Projekt handelt.
Such einfach mal nach ".Create" und "GetMem"/"New" o.Ä.
Überprüfe anschließend, ob letzendlich alles allozierte auch zu 100% freigegeben wird.

Jou -- das war mein Vorgehen, bevor ich das hier postete.

Es sind nicht allzu viele Klassen und Units -- vielleicht mal eine kleine Pause -- und dann mit Kaffee...

Vielen Dank euch allen!

Jazzman

[Union]

Versuch mal im destructor der Klasse ein SetLength(fHfgkFarbe, 0)

[Jazzman_Marburg]

Zitat von Union:

Versuch mal im destructor der Klasse ein SetLength(fHfgkFarbe, 0)

Keinerlei Wirkung -- ReportMemoryLeak ("37-44 Bytes: Unknown x 1") unverändert.

Delphi-Quellcode:

destructor TPaletto.Destroy;
begin

  inherited Destroy;
  SetLength(fHfgkFarbe, 0);

end;

Danke!

[Klaus01]

Zitat von Jazzman_Marburg:

Zitat von Union:

Versuch mal im destructor der Klasse ein SetLength(fHfgkFarbe, 0)

Keinerlei Wirkung -- ReportMemoryLeak ("37-44 Bytes: Unknown x 1") unverändert.

Delphi-Quellcode:

destructor TPaletto.Destroy;
begin

 
  SetLength(fHfgkFarbe, 0);
  inherited Destroy;
end;

Danke!

.. und wenn Du inherited Destroy als letztes aufrufst?

Grüße
Klaus

[Union]

Und so?

Delphi-Quellcode:

destructor TPaletto.Destroy;
begin
  SetLength(fHfgkFarbe, 0);
  fHfgkFarbe := nil;
  inherited Destroy;
end;

[Sir Rufo]

Ein Array (dynamisch oder statisch) muss nicht freigeben werden. Das ist also mal nicht der Grund.

Unknown (ganz alleine für sich) ist auch eher ein Hinweis auf einen mit GetMem /AllocMem allozierten Speicher-Bereich.

Sourcen möchtest du aber wohl hier nicht reinstellen?

Dann wird es schwierig, denn so ist das ein Blindflug

[Jazzman_Marburg]

Zitat von Union:

Und so?

Delphi-Quellcode:

destructor TPaletto.Destroy;
begin
  SetLength(fHfgkFarbe, 0);
  fHfgkFarbe := nil;
  inherited Destroy;
end;

Dito - exakt der selbe Leak-Report.

Zitat von Sir Rufo:

[...]
Unknown (ganz alleine für sich) ist auch eher ein Hinweis auf einen mit GetMem /AllocMem allozierten Speicher-Bereich.

Sourcen möchtest du aber wohl hier nicht reinstellen?

Dann wird es schwierig, denn so ist das ein Blindflug

Ein explizites GetMem /AllocMem nutze ich nicht.

Sourcen wären im Prinzip überhaupt kein Problem -- aber es ist doch einiges an Code, und das wäre wirklich nicht ok, euch meinen Fehler im meinem Code suchen zu lassen. Sehr lieb!

Ich werde morgen einfach mal eine große Auskommentierungsaktion starten und mal systematisch rang gehen.

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.

Vielen Dank an alle - super Truppe

Gruß
Jazzman

[EgonHugeist]

StrNew(), ReallocMem() ???

Ist dein Project irgendwie FPC portable? Hier ist FPC Meilen vorraus mit deren HeapTracing. Hier kann man fast ganz exakt festsetellen, wo die MemLeaks "offen" bleiben und deren Ursache ergründen. Benutzt du noch eine Ansi-Delphi? Dann könnte die MemCheck.pas genauere Infos geben..

[sx2008]

Zitat von Jazzman_Marburg:

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.