Delphi 7 - Speicherleck

[SonOfOdin]

Hallo zusammen,
ich bin auf der Suche nach einem Speicherleck...
Es handelt sich um eine Applikation die in Delphi 7 geschrieben ist.

Ich habe bereits FastMM4 eingebunden und konnte so einige Dinge ausräumen.
Wenn ich das Programm nach gut einem Tag Laufzeit beende kommt vom FastMM4 nun keine Meldung mehr.

Das Problem ist, dass das Programm in 24h gut 100MB Speicher belegt.
In 48h entsprechend 200MB.

Frage 1) Bei diesem Verhalten des Programms, wenn der FastMM4 nichts mehr findet; bedeutet das, dass die Objekte die den Speicher belegen beim Herunterfahren wieder ordnungsgemäß entsorgt werden und der FastMM4 daher nichts finden kann?

Frage 2) Gibt es eine Möglichkeit zur Laufzeit zu sehen, von welchen Objekten wieviele Instanzen erzeugt wurden und wieviel Speicher diese belegen?
(Ich habe bereits die üblichen Verdächtigen angesehen, z.B. die .Create Aufrufe, oder TStringLists und TLists mit Inhalt, kann aber nichts auffälliges entdecken...)


Gruß

[nahpets]

Beschreib bitte mal, was das Programm so alles macht.

Weniger aus technischer Sicht, sondern seine allgemeine Aufgabe.

Ist es z. B. eine Datenbankanwendung?
Oder nutzt es irgendwelche ActiveX-Controls?
Hat es eine WMI-Schnittstelle?

Was auch immer, bitte eine kurze Beschreibung dessen.

P. S.: Bei den obigen Beispielen von mir hab' ich unter Delphi 7 schon ähnliches Verhalten feststellen können. Dabei kamen die Speicherlecks aber aus den genutzten "Fremdbestandteilen", so dass ich in Delphi 7 keinerlei Einfluss auf die Speicherlecks nehmen konnte.

[SonOfOdin]

Hallo,

das Programm implementiert ist eine Socket-Kommunikation zu einem anderen Lieferanten.
Wir senden Befehle und empfangen Statusupdates.

Die Befehle die wir senden stehen in einer MSSQL Datenbank und werden dort von anderen Applikationen eingetragen.
Die Statusupdates beziehen sich entsprechend auch auf die Datenbank und werden von dieser Applikation dort eingetragen.

Zusätzlich ist eine einfache Oberfläche integriert, die hauptsächlich dazu da ist Debug auszugeben,
was wurde gesendet, was wurde empfangen, Alive-Bit, Fehlermeldungen etc.

Das ist eigentlich auch schon alles

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

[Bambini]

Zitat:

Zitat von SonOfOdin (Beitrag 1341575)

Frage 1) Bei diesem Verhalten des Programms, wenn der FastMM4 nichts mehr findet; bedeutet das, dass die Objekte die den Speicher belegen beim Herunterfahren wieder ordnungsgemäß entsorgt werden und der FastMM4 daher nichts finden kann?

Dann kann FastMM auch nicht helfen. Auch wenn es Objekte sind die nicht über den FastMM gehen, wie z.B. die ADO Komponenten.

Zitat:

Zitat von SonOfOdin (Beitrag 1341575)

Frage 2) Gibt es eine Möglichkeit zur Laufzeit zu sehen, von welchen Objekten wieviele Instanzen erzeugt wurden und wieviel Speicher diese belegen?
(Ich habe bereits die üblichen Verdächtigen angesehen, z.B. die .Create Aufrufe, oder TStringLists und TLists mit Inhalt, kann aber nichts auffälliges entdecken...)

Vielleicht hilft das Schreiben einer DEBUG Datei um das Erzeugen und Freigeben zu sehen.

[Sir Rufo]

Diese "Speicherlecks" sind beliebt bei Klassen, die sich von

Delphi-Quellcode:

TComponent

ableiten.

Delphi-Quellcode:

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

Jeder Aufruf von

Delphi-Quellcode:

foo

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

Da

Delphi-Quellcode:

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

Delphi-Quellcode:

foo

weiter ansteigen.

[SonOfOdin]

Zitat:

Zitat von nahpets (Beitrag 1341601)

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:

Zitat von SonOfOdin (Beitrag 1341609)

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:

Zitat von stahli (Beitrag 1341629)

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 :)