Memory Leak: Ursache finden

[Jazzman_Marburg]

Hallo.
Bei der Suche nach der Ursache für einen kleinen Memory-Leak, wäre ich sehr dankbar für jedwede Hilfe.
Nachdem ich mit "ReportMemoryLeaksOnShutDown := True;" die Nachricht (UexpectedMemoryLeak.jpg) über einen Memory-Leak erhalten habe, aber die Ursache nicht finden konnte, habe ich MadExcept mal ausprobiert.
Wie erwartet, gibt es auch einen Leak-Report (LeakReport.jpg) aus dem ich leider auch nicht schlau werde. Wenn ich in diesem Leak-Report auf die im Bild hervorgehobene Zeile im CallStack Doppelklicke, komme ich im meinem Source-Code auf diese Zeile:

Delphi-Quellcode:

  setlength( fHfgkFarbe, fAnzFarben );

Das kann aber doch nicht die Ursache für den Mem-Leak sein, oder?

Jemand eine Idee, was man man aus dem MadExcept noch weiter auslesen kann, um die Urasche für den Memory-Leak auf die Spur zu kommen?

Vielen Dank
Jazzamn

[Aphton]

Kann durchaus möglich sein; zb. wenn der Speicher für den Datentyp dieses Arrays dynamisch alloziert wird (wenn es sich zb. dabei um eine Klasse handelt)

[Jazzman_Marburg]

Hallo.

Vielen Dank - aber das kann ich ausschließen:
Bei

Delphi-Quellcode:

setlength( fHfgkFarbe, fAnzFarben );

wird die Länge eines Array of Integer mittles einfachem Integer (fAnzFarben) bestimmt.

Steht in ähnlicher Form öfters im Source -- schließe ich somit als Verdächtigen aus.

Gruß
Jazzman

[stahli]

Inhaltlich kann ich nicht helfen.
Evtl. könntest Du die Trial von EurekaLog versuchen.
Vielleicht hilft die ja noch genauer?

[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.

[Union]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1203844)

Hallo.
Steht in ähnlicher Form öfters im Source -- schließe ich somit als Verdächtigen aus.
Gruß
Jazzman

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?

[sx2008]

Ein kleiner Tipp: durchsuche den gesamten Sourcecode nach "

Delphi-Quellcode:

destructor Destroy;

"; wenn irgendwo der Zusatz "

Delphi-Quellcode:

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

Delphi-Quellcode:

inherrited

aufgerufen wurde.

[Jazzman_Marburg]

Zitat:

Zitat von sx2008 (Beitrag 1203866)

Ein kleiner Tipp: durchsuche den gesamten Sourcecode nach "

Delphi-Quellcode:

destructor Destroy;

"; wenn irgendwo der Zusatz "

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Union (Beitrag 1203851)

[...] 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:

Zitat von Aphton (Beitrag 1203850)

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

Delphi-Quellcode:

SetLength(fHfgkFarbe, 0)

[Jazzman_Marburg]

Zitat:

Zitat von Union (Beitrag 1203869)

Versuch mal im destructor der Klasse ein

Delphi-Quellcode:

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!