Delphi 7 - Speicherleck

[Sir Rufo]

Diese "Speicherlecks" sind beliebt bei Klassen, die sich von TComponent ableiten.

Delphi-Quellcode:

procedure foo;
begin
  TEdit.Create( Application );
end;

Jeder Aufruf von foo erzeugt eine Instanz und belegt somit Speicher. Diese Instanz wird aber nie wieder freigegeben, mit einer Ausnahme:

Da Application der Owner ist, wird die Instanz beim Beenden durchaus freigegeben. Darum sagt FastMM: "Kein Speicherleck!" und trotzdem wird der Speicherverbrauch mit jedem Aufruf von foo weiter ansteigen.

[SonOfOdin]

Zitat von nahpets:

Wie erfolgt die Debug-Ausgabe?

In 'nem Memo oder in eine Datei?
Wenn in eine Datei, wie wird der Dateiinhalt (wenn überhaupt durch das Programm) angezeigt?
Alles, was während der Laufzeit des Programmes so angefallen ist oder z. B. nur die letzten 10 Einträge (oder sowas in der Art)?
Wie umfangreich ist diese Ausgabe?

Wenn Du Das Programm im Taskmanager beobachtest, was nimmt (außer der Speicherbelegung) noch zu? Z. B. Handles, Benutzerobjekte ...?

Hi,
die Ausgabe erfolgt in ein Memo.
Das Memo hält 500 Zeilen. Wird der Eintrag 501 fällig wird der Eintrag 0 gelöscht.
Die Ausgaben sind weiter nicht umfangreich... Sagen wir ~ 50 Zeichen pro Zeile.

Im Taskmanager nimmt die Anzahl der Handles ebenfalls zu.


@Sir Rufo:
TComponent wird nicht verwendet in der Applikation.
Wir haben eine eigene Delphi-Lib in der Firma, in der die TComponent vielfach eingesetzt ist.
Aber die Lib ist in allen Programmen im Einsatz die wir so haben (Delphi 7). Daher würd ich diese Lib mal ausschließen, da das Problem in den anderen Applikationen nicht auftritt

[nahpets]

Zitat von SonOfOdin:

Hi,
die Ausgabe erfolgt in ein Memo.
Das Memo hält 500 Zeilen. Wird der Eintrag 501 fällig wird der Eintrag 0 gelöscht.
Die Ausgaben sind weiter nicht umfangreich... Sagen wir ~ 50 Zeichen pro Zeile.

Im Taskmanager nimmt die Anzahl der Handles ebenfalls zu.


@Sir Rufo:
TComponent wird nicht verwendet in der Applikation.
Wir haben eine eigene Delphi-Lib in der Firma, in der die TComponent vielfach eingesetzt ist.
Aber die Lib ist in allen Programmen im Einsatz die wir so haben (Delphi 7). Daher würd ich diese Lib mal ausschließen, da das Problem in den anderen Applikationen nicht auftritt

Das Letztgenannte (an SirRufo gerichtete) gilt aber nur, wenn aus der Lib zur Laufzeit nicht "permanent" neue Objekte erstellt werden. Andernfalls kann der genannte Fehler auch in der Lib liegen, fällt bei anderen Programmen nur nicht auf, wenn sie nicht während der Laufzeit kontinuierlich neue Objekte erzeugen.

Wenn die Handles zunehmen, so wird auch zunehmend Speicher verbraucht. Da wirst Du mal nachsehen müssen, wo die Handels "erstellt" und nicht wieder aufgeräumt werden (1. Speicherlecksuchbaustelle in der Gegend um die Sockets herum).

Bin mir nicht so ganz sicher, aber die Methode "Log-in-Memo" hab' ich auch schonmal irgendwann genutzt. Wenn 'ne bestimmte Zeilenzahl erreicht ist, werfe man die erste Zeile weg, bevor man hinten noch eine dranhängt. Da hatte ich auf die Dauer irgendwann auch Speicherprobleme. Weiß aber nicht mehr, in welchem Umfang.

Zum Anzeigen von Log-Dateien benutze ich seit einiger Zeit den ATViewer.
Geloggt wird in eine Datei. Der Viewer wird einfach aufs Fomuler "gepappt". er kann so konfiguriert werden, dass er bei "Neuerungen" an der Datei automatisch an deren Ende wandert. So sieht man in der Oberfläche immer die neuesten Zeilen, kann aber per Scrollbar natürlich durch die ganze Datei "Wandern". Mit zunehmender Dateigröße scheint er aber nicht zunehmend Speicher zu verbrauchen, er lädt wohl nur soviel aus der Datei, wie er auch anzeigen kann. Zumindest sind mir im Zusammenhang mit seiner Nutzung keine exorbitanten Speicherzuwächse aufgefallen.

Die Logdateien erstelle ich immer so, dass sie nicht zu groß werden, z. B. alle 24 Stunden wird 'ne neue angefangen (oder alle Stunde ...).
Dadurch spare ich mir die "Stringmengenumkopiererei" in der Oberfläche. Log-Dateien kann man ja, wenn sie nicht historisiert werden müssen, regelmäßig wegwerfen oder, wenn eine bestimmte Dateigröße erreicht wurde, löschen und wieder neu erstellen.

[stahli]

Hast Du mal einen Memoryprofiler wie DDDebug oder AQTime versucht?

[SonOfOdin]

Zitat von stahli:

Hast Du mal einen Memoryprofiler wie DDDebug oder AQTime versucht?

Wir haben hier eine uralte Version von AQTime, die aber unter Win7 64Bit nicht zu laufen scheint.
DDDebug kannte ich bisher nicht - habe es grade mal in mein Projekt integriert (die Trial Version)
Mal schauen was es liefert.
danke mal soweit

[SonOfOdin]

Sorry für den Doppelpost:

Der Screenshot im Anhang:

Für was steht + - und Diff ?
Create - Destroy - und "Übrig geblieben"?

Die Doku von DDDebug ist wohl von Version 0.96 wo es das vermutlich noch nicht gab...

[sahimba]

Zitat von SonOfOdin:

Sorry für den Doppelpost:
Der Screenshot im Anhang:
Für was steht + - und Diff ?
Create - Destroy - und "Übrig geblieben"?
Die Doku von DDDebug ist wohl von Version 0.96 wo es das vermutlich noch nicht gab...

Hallo

Ich bin der Autor von DDDebug. Wo hast Du die Version runtergeladen? Die Doku sollte aktualisiert sein. Ich schaue mal, ob das da beschrieben ist. Und ergänze es gegebenenfalls.

Das "Statistik"-Tab ist auch das erste, dass ich verwende wenn ich nach solch wachsendem Speicher suche. Unten gibt es einen Button "Reset", welcher die Counter der einzelnen Klassen zurücksetzt. +/- ist dann die Anzahl der Instanzen einer jeden Klasse, welche seit diesem Zeitpunkt "created" bzw. "destroyed" wurden. (*)
In der Regel ist aber schon die Anzahl der "Live"-Instanzen ein gutes Indiz und liefert Anhaltspunkte, wonach zu suchen ist.


(*) In Deinem Screenshot wurden bspw. seit dem Zeitpunkt der Aktivierung des Trackers 2461 Instanzen der Klasse TBitmapImage erzeugt und von diesen 2460 wieder freigegeben. Eine Instanz ist derzeit noch "im Speicher".