Speicherleck, ABER warum?

[bluethund]

Hallo miteinander.

Ich hoffe mir kann jemand helfen. Mein Programm verbraucht immer mehr Speicher, bis der Arbeitsspeicher voll ist. Sobald ich keine Dateien mehr zu übertragen habe, steigt der Speicherverbrauch auch nicht mehr an.

Ich habe das Problem auf den Netzwerk-Code eingegrenzt und auch mehrere Tools zum Aufspüren von Memory Leaks bereits verwendet, aber die haben nichts gefunden.

Ich habe erst vor kurzem mit Delphi angefangen und es könnte sein, dass ich vielleicht etwas nicht richtig mache. Ich habe schon andere Programmiersprachen verwendet, aber das ist mein erstes Netzwerkprogramm. Meine 2-wöchige Suche im Internet hat keine brauchbaren Hinweise oder Lösungen gebracht.

Ich bin für jede Hilfe dankbar.

Delphi-Quellcode:

procedure TRecvFileThread.Execute;
var
  client : TIdTcpClient;
begin
  client := nil;
  try
    client := TIdTcpClient.Create(nil);
    client.Host := Form1.OtherPcIP;
    client.Port := Form1.FocPort;

    while not Terminated do
    begin
      try
        client.Connect;
        while not Terminated do
        begin
          Networking(client);
        end;
      finally
        client.Disconnect;
        Sleep(SLEEP_THREADS);
      end;
    end;
  finally
    client.Free;
  end;
end;

procedure TRecvFileThread.Networking(var client : TIdTcpClient);
var
  path, path_foc, filename, resp : string;
  filestr : TFileStream;
  filesize : int64;
begin
          client.WriteLn('SEND');
          resp := client.ReadLn(EOL);

          if resp = 'READY' then
          begin
            filename := client.ReadLn(EOL);
            filesize := StrToInt64(client.ReadLn(EOL));
            path := dir + filename;
            path_foc := path + '.foc';

            filestr := nil;
            try
              filestr := TFileStream.Create(path_foc, fmCreate);
              client.ReadStream(filestr, filesize);
            finally
              filestr.Free;
            end;

            CopyFile(PChar(path_foc), PChar(path), false);
            client.WriteLn('OK');
            DeleteFile(PChar(path_foc));
          end
          else if resp = 'NONE' then
            Sleep(SLEEP_THREADS)
          else
            client.Disconnect;
end;

[Christian Seehase]

Moin bluethund,

erst einmal herzlich willkommen hier in der Delphi-PRAXiS.

also einen Grund für ein Speicherleck kann ich direkt nicht erkennen.
Es kann eigentlich nur noch an den Indys liegen. Da müsstest Du mal schauen (speziell natürlich in den Destruktoren)

Mir ist aber etwas anderes aufgefallen, nämlich Deine Verwendung des Resourcenschutzblockes.

Der Resourcenschutzblock macht erst Sinn, nachdem man eine Resource erfolgreich belegt hat.
Es sollte also so aussehen:

Delphi-Quellcode:

variable := TKlasse.Create;
try
  // Mach was mit der Resource
finally
  variable.free; // oder FreeAndNil(variable);
end;

Wenn ein Create schon schiefgeht, ist ein Freigeben nicht möglich.
(gilt analog natürlich auch für andere Resourcen, wie, z.B., Handles.

Ausserdem finde ich es gefährlich, dass Du für Networking einen var-Parameter verwendest, da Du ja schon ein erzeugtes Objekt übergibst, und es nicht erst in Networking erzeugst.
Mit var läufst Du Gefahr in der Prozedur den Pointer im Parameter mit etwas anderem zu überschreiben, und so ein Speicherleck zu erzeugen.
Deklariere den mal lieber als const. Eigenschaften ändern usw. kannst Du trotzdem.

Zudem ist es bei Funktionen, die Erfolg und Misserfolg melden (z.B. CopyFile, DeleteFile) den Rückgabewert zu prüfen.
Du gibst OK zurück, weisst aber gar nicht, ob CopyFile erfolgreich war. ;-)

[Dezipaitor]

Verwende einen Speichermanager, wie MemCheck oder FastMM .
Durch Spekulation wird man nicht weit kommen.

[bluethund]

Zitat:

Zitat von Dezipaitor

Verwende einen Speichermanager, wie MemCheck oder FastMM .
Durch Spekulation wird man nicht weit kommen.

Mit beiden habe ich das Problem schon untersucht, aber die gefunden Stellen scheinen viel zu gering. Aber vielleicht übersehe ich was!

Code:

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

13 - 20 bytes: TObjectList x 3, TStatusBuffer x 2, Unknown x 3
29 - 36 bytes: TWinHelpViewer x 1
37 - 52 bytes: THelpManager x 1

[Dezipaitor]

Normalerweise bekommst du noch mehr Informationen. z.B. einen Speicherauszug und einen Stackaufrufablauf :

Zitat:

--------------------------------xxxxxxxxxxxxxxxxxxx--------------------------------
Diese Anwendung hat Speicher-Lecks. Die kleineren Speicher-Lecks sind (ausschließlich von Zeigern registrierte Lecks):

5 - 12 bytes: TFileStream x 2

Hinweis: Speicherlecks werden in einer Textdatei im selben Ordner wie diese Anwendung protokolliert. Um die Speicherleckprüfung zu deaktivieren, deaktivieren sie die "{$ EnableMemoryLeakReporting} -Option".

--------------------------------xxxxxxxxxxxxxxx--------------------------------
Ein Speicher-Leck hat folgende Größe : 12

Stackverfolgung - Speicherpuffer wurde zugeordnet (Rückgabeadresse):
4029C3 [system.pas][System][@GetMem][2447]
403B3F [system.pas][System][TObject.NewInstance][8368]
403F06 [system.pas][System][@ClassCreate][9027]
424626 [classes.pas][Classes][TFileStream.Create][5100]
43344D [Graphics.pas][Graphics][FreeMemoryContexts][4670]
4CC3B9 [modules\USM_SecureObjectsTests.pas][USM_SecureObjectsTests][TSecureFileObjectTests.Test_GetSACL][529]
4A29C1 [TestFramework.pas][TestFramework][TTestCase.Invoke][1810]
4A2B31 [TestFramework.pas][TestFramework][TTestCase.RunTest][1833]
42C312 [classes.pas][Classes][StdWndProc][10966]

Der Speicherpuffer wird gegenwärtig für ein Objekt der folgenden Klasse verwendet: TFileStream

The allocation number is: 7442

Aktueller Speicherauszug von 256 Byte, angefangen an der Zeigeradresse: 1A9F3B8:
24 DF 41 00 38 07 00 00 BF C8 EB 80 80 80 80 80 00 00 00 00 51 F7 A9 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 5A 27 00 00 C3 29 40 00 12 5A 40 00 4C F1 43 00 FC F6 43 00 2B F4 43 00
F1 F8 43 00 5F 92 40 00 B7 00 4A 00 A9 39 4A 00 E3 29 40 00 2C 5A 40 00 DB F1 43 00 81 F2 43 00
A3 3B 40 00 D8 F3 43 00 A3 3B 40 00 E5 F7 43 00 A3 3B 40 00 0C 00 00 00 00 00 00 00 3F 48 60 06

Man sieht hier z.B. , dass die Methode TSecureFileObjectTests.Test_GetSACL, den Fehler verursacht. Es geht zwar noch tiefer, jedoch sind das interne Funktionen,
die man nicht unbedingt als erstes unter Verdacht setzten muss.


Ich hab die folgenden Compilerdirektiven für FastMM eingeschaltet:

LogErrorsToFile;FullDebugMode;ManualLeakReportingC ontrol;LogMemoryLeakDetailToFile

[bluethund]

@Dezipaitor:

Ich hab mein Programm mal mit FastMM4 eine Weile laufen gelassen und den Report als Attachment angehängt.
Vielleicht hast du eine Eingebung.

Ich bin inzwischen Zeit ziemlich am Ende mit meinem Latein und das Internet gibt auch nichts her. :(

[Dezipaitor]

Die Logdatei ist wirklich nur hilfreich, wenn man auch den Quelltext dazu hat.

[bluethund]

Zitat:

Zitat von Dezipaitor

Die Logdatei ist wirklich nur hilfreich, wenn man auch den Quelltext dazu hat.

Entschuldige, dass wäre natürlich besser gewesen!

Ich habe meinen Code überarbeitet und zum Testen in ein eigenes Programm gesteckt. FastMM4 und EurekaLog melden keine Memory Leaks mehr. Der Speicherverbrauch ist mir aber immer noch ein Rätsel. Ich werde das Programm heute Nacht mal durchlaufen lassen.

Der Code des Programms befindet sich im Anhang. Vielleicht kann mir jemand sagen, ob ich noch einen Denkfehler im meinem Code habe.

Zum besseren Verständnis:
Mein Code ist Teil eines Programms zur Überwachung einer Anlagensteuerung, die ihre Laufzeitdaten in Dateien hält. Fällt nun der Rechner mit der Steuerungssoftware aus, so nach wenigen Sekunden auf dem zweiten Rechner umgeschaltet werden. Dafür müssen natürlich die Dateien mit den Laufzeitdaten ständig auf den zweiten Rechner übertragen werden. Die Versuche mit SMB-Freigaben waren nicht überzeugen und so kam ich auf die Idee mit der ständigen TCP-Verbindung. Die Verbindung wird bei Abbruch automatisch wieder aufgebaut und die Daten weiter übertragen. Zur Erhöhung der Sicherheit überträgt die Verbindung normalerweise auch eine CRC32-Prüfsumme, die aber zum Debuggen des Problems entfernt wurde.

[bluethund]

Hallo nochmal.

Also bei längeren Testläufen stellte sich heraus, dass das Problem bereits verschwunden ist. Nun habe ich keine Ahnung, was genau das Problem behoben hat. Leider habe ich keine Zeit nach der genauen Ursache zu suchen. IMHO lag es wahrscheinlich am Borland Memory Manager in Kombination mit ein paar Programmierfehlern.

Ich habe die beiden Prozeduren, die für den Dateitransfer zuständig sind, in eine seperate Datei kopiert und diesem Beitrag angehängt. Vielleicht kann daraus noch jemand was lernen.

Vielen Dank an alle, die mir geholfen haben.