Memory Leak: Ursache finden

[Jazzman_Marburg]

Hallo.

Vielen Dank - aber das kann ich ausschließen:
Bei 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 von Jazzman_Marburg:

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 "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

[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