Fehler mit Socket komponente

[1aa]

Ich hab zu test zwecken ein programm geschrieben welches sich mit der TClientSocket Komponente an einem TServerSocket anmelden soll klappt auch alles ohne Probleme.

Wenn der "Server" nicht läuft soll sie in regelmäßigen abständen versuchen eine Verbindung auf zu bauen

Code Ausschnitte:

Delphi-Quellcode:

    .....
      CS1: TClientSocket;
      TimerCon: TTimer;
    ....
      procedure CS1Connect(Sender: TObject; Socket: TCustomWinSocket);
      procedure CS1Disconnect(Sender: TObject; Socket: TCustomWinSocket);
      procedure CS1Error(Sender: TObject; Socket: TCustomWinSocket;
        ErrorEvent: TErrorEvent; var ErrorCode: Integer);
      procedure CS1Read(Sender: TObject; Socket: TCustomWinSocket);
      procedure TimerConTime(Sender: TObject);
    ....
constructor TClient.Create;
begin
....
  CS1 := TClientSocket.Create(nil);
  cs1.Host := IP;
  CS1.Port := Port;
  CS1.OnConnect := CS1Connect;
  CS1.OnDisconnect := CS1Disconnect;
  CS1.OnError := CS1Error;
  CS1.OnRead := CS1Read;
....
  TimerCon := TTimer.Create(nil);
  TimerCon.Interval := TimeIntervCon;
  TimerCon.OnTimer := TimerConTime;
  TimerCon.Enabled:=True;
end;
....

procedure TClient.CS1Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
  Cs1.Close;
  ErrorCode := 0;
end;

procedure TClient.TimerConTime(Sender: TObject);
begin
  if Not(CS1.Socket.Connected) then
    Begin
      CS1.Open;
    End;
end;

Wenn das programm jetzt eine zeitlang läuft, "frisst es kontinuierlich immer mehr Speicher und irgend wann kommt die Fehlermeldung (siehe Anhang).


Meine Frage jetzt wie kann ich den Speicher bereinigen bzw woran konnte der fehler liegen?

MFG Ertr

[Union]

Delphi-Quellcode:

CS1 := TClientSocket.Create(nil);
TimerCon := TTimer.Create(nil);

Irgendwo mußt Du auch ein Free machen, sonst verstopfen die TClientSocket-Instanzen und TTimer den Speicher.

[1aa]

sorry vergessen mit zu posten...

Delphi-Quellcode:

destructor TClient.Destroy;
begin
  //Timer abklemmen
  TimerCon.Enabled := false;
  TimerCon.OnTimer := nil;
  TimerCon.Free;
.....
  //Socket abklemmen
  if CS1.Active then Cs1.Close;
  CS1.OnConnect := nil;
  CS1.OnDisconnect := nil;
  CS1.OnError := nil;
  CS1.OnRead := nil;
  Cs1.Free;
....    
  inherited;
end;

[sx2008]

Gibt mal in deinem Profil an, welche Delphi Version du verwendest.
Bei neueren Delphi Versionen ist der Speichermanager FastMM standardmässig enthalten; bei älteren Versionen (< Delphi 2006) kann man diesen Speichermanager nachrücsten.

Man kann den Speichermanager anweisen alle Speicherlecks bei Programmende zu melden:

Delphi-Quellcode:

// in der Projektdatei
begin
  Application.Initialize;
  ReportMemoryLeaksOnShutdown := True;  // <===

Zusätzlich sollte man in den Projektoptionen die TD32-Debug-Info anschalten.

[1aa]

Bin mir nicht sicher welche Version es war glaube aber Enterprise.....:oops:

Danke für den Tipp kenn ich mich zwar noch nicht aus werd mir aber mal ein Tut zu suchen....

[1aa]

Zitat:

Zitat von sx2008 (Beitrag 1224521)

Man kann den Speichermanager anweisen alle Speicherlecks bei Programmende zu melden:

Delphi-Quellcode:

// in der Projektdatei
begin
  Application.Initialize;
  ReportMemoryLeaksOnShutdown := True;  // <===

Zusätzlich sollte man in den Projektoptionen die TD32-Debug-Info anschalten.

Hat mir leider nicht weiter geholfen laut Speichermanager gibt es keine Lecks und trotzdem hängt sich das programm nach einer zeit mit der Fehlermeldung aus dem 1. post auf....

[Union]

Laß Dir mal im Taskmanager die Anzahl der offenen Handles ausgeben. Vielleicht wird ja der Socket nach erfolgreichem Aufbau der Verbindung nicht korrekt geschlossen?

[Zacherl]

1. Liest du in deinem OnRead Event auch wirklich die Daten aus dem TCP Buffer aus?
2. Selbige Frage für die Gegenseite der Client/Server Anwendung

Wenn deine Gegenstelle permanent Daten schickst, du aber auf deiner Seite nichts aus dem Buffer ausliest, wird dieser logischerweise irgendwann voll sein.

Magst du eventuell mal etwas mehr Code posten?

[1aa]

Wenn der Client einen Server zum verbinden findet gibt es ja kein problem das problem tritt nur auf wenn kein Server vorhanden ist und der client versucht eine Verbindung auf zu bauen.

Code:

Delphi-Quellcode:

unit U_Spy_Client;

interface

uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ScktComp, ExtCtrls;

const IP = 'XXX.XXX.XXX.XXX';
      PORT = XXXXX;
      TimeIntervCon = 1000;

Type
  TClient = class(TObject)
    private
      CS1: TClientSocket;
      TimerCon: TTimer;
      iCon : String;
      iDis : String;
      procedure Disco;
      procedure CS1Connect(Sender: TObject; Socket: TCustomWinSocket);
      procedure CS1Disconnect(Sender: TObject; Socket: TCustomWinSocket);
      procedure CS1Error(Sender: TObject; Socket: TCustomWinSocket;
        ErrorEvent: TErrorEvent; var ErrorCode: Integer);
      procedure CS1Read(Sender: TObject; Socket: TCustomWinSocket);
      procedure TimerConTime(Sender: TObject);
      procedure Initial;
      procedure SockFree;
    public
      constructor Create;
      destructor Destroy; override;
  end;

implementation

constructor TClient.Create;
begin
  //Sockel------------------------
  Initial;
  //Timer Verbindung aufbauen-------------------------
  TimerCon := TTimer.Create(nil);
  TimerCon.Interval := TimeIntervCon;
  TimerCon.OnTimer := TimerConTime;
  TimerCon.Enabled:=True;
end;

destructor TClient.Destroy;
begin
  //Timer abklemmen
  TimerCon.Enabled := false;
  TimerCon.OnTimer := nil;
  TimerCon.Free;
  //Socket abklemmen
  SockFree;    
  inherited;
end;

procedure TClient.Disco;
begin
  Cs1.Close;
end;

procedure TClient.CS1Connect(Sender: TObject; Socket: TCustomWinSocket);
begin
  iCon := 'Verbindung Aufgebaut: ' + datetimetostr(Now);
end;

procedure TClient.CS1Disconnect(Sender: TObject; Socket: TCustomWinSocket);
begin
  iDis := 'VerbindungGetrennt: ' + datetimetostr(Now);
end;

procedure TClient.CS1Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
  Disco;
  ErrorCode := 0;
end;

procedure TClient.CS1Read(Sender: TObject; Socket: TCustomWinSocket);
var s: String;
begin
  s := Socket.ReceiveText;
  if s = 'Test' then
   Begin
     Disco;
     Application.Terminate;
   End
end;

procedure TClient.TimerConTime(Sender: TObject);
begin
if not(CS1.Socket.Connected)
 then
    Begin
     SockFree;
     Initial;
      CS1.Open;
    End;
end;

procedure TClient.Initial;
begin
  CS1 := TClientSocket.Create(nil);
  cs1.Host := IP;
  CS1.Port := Port;
  CS1.OnConnect := CS1Connect;
  CS1.OnDisconnect := CS1Disconnect;
  CS1.OnError := CS1Error;
  CS1.OnRead := CS1Read;
end;

procedure TClient.SockFree;
begin
  if CS1.Active then Cs1.Close;
  CS1.OnConnect := nil;
  CS1.OnDisconnect := nil;
  CS1.OnError := nil;
  CS1.OnRead := nil;
  Cs1.Free;
end;

end.

PS: Das on Read ist nur bsp...

[Union]

Nach welcher Zeitspanne stürzt es denn ab? Ich lasse das hier schon eine halbe Stunde laufen und nix passiert. Habe sogar noch einen Logging-Event eingebaut.

[1aa]

auf meinem Testsystem nach ca 20 - 25 min

[Zacherl]

Ohne jetzt ein konkretes Problem zu sehen: Du musst das Socket nicht vor jedem Connect neu erstellen. Es reicht vollkommen aus, wenn der der alten Instanz sagst, dass sie erneut versuchen soll eine Verbindung herzustellen.

Das weiteren würde ich mit blocking Sockets innerhalb eines Thread arbeiten. In diesem Falle bekommst du einen Disconnect unmittelbar mit, wenn der blocking Call dann failt und kannst direkt versuchen die Verbindung erneut herzustellen.

Mit non blocking Sockets kann es dir sogar passieren, dass dein Timer die ".Open" Methode mehrfach während eines schon laufenden Verbindungsaufbaus aufruft (wenn der Verbindungsaufbau länger als 1 Sekunde dauert).

[1aa]

ok das mit dem blocking Sockets werde ich noch mal testen....

Das mit dem neu erstellen vor jedem connect hat ich nur zu Testzwecken ausprobiert ob das was ändert.... hat es aber nicht^^ :?

Ich hatte heute etwas zeit zum Testen wann die Fehlermeldung kommt hängt vom jeweiligem System ab.... auf meinem Netbook kommt sie nach ca. 20-25min auf meinem Hauptrechner erst nach ca. 5-6 h

Muss wahrscheinlich an der Socket Verarbeitung von Win liegen...das mit jedem Connect versuch der Fehlschlägt mehr Arbeitsspeicher belegt und nicht wieder freigegeben wird...

Ach ja und auf die Frage mit den Handles: Start ist bei 82 und je connect Versuch wird die zahl um 2 erhöht...sobald eine Verbindung aufgebaut wurde bleibt die Zahl konstant wenn die verbindung wieder abbricht läuft der zähler wieder weiter... :x

[Zacherl]

Kannst du das Programm auf deinem Laptop mal im Debugger testen und wenn der Fehler auftritt, anschauen welcher (WinAPI) Funktionsaufruf dazu führt? Eventuell ist die ScktComp Implementation in deiner Delphi Version fehlerhaft und leaked tatsächlich Handles. Ich teste das Verhalten gleich mal bei mir.

Edit: Kann das Verhalten bezüglich der Handles auch für XE4 unter Win8 bestätigen. Es werden bei jedem erfolglosen Verbindungsversuch 2 Handles geleaked.
Edit: Bei blocking Sockets funktioniert alles normal. Ich kann nur spekulieren, aber ich vermute mal, dass bei den asynchronen Sockets irgendwelche Handles zwecks Error Reporting oä. geöffnet bleiben. Wenn du mal versuchst in einer Schleife z.b. 100x zu einem nicht verfügbaren Host zu connecten, wirst du feststellen, dass sämtliche Fehlermeldungen erst nach Ablauf der Schleife angezeigt werden. Irgendwo muss die Komponente oder das System ja vermerken, dass noch eine Fehlermeldung ausstehen. Das dürfte das Memory Leak erklären.

[1aa]

Spitze Danke für deine Hilfe jetzt funkt es

:-D:thumb:

[Union]

Wie hast Du es jetzt konkret gelöst? Bei meinen Tests mit WinXP und Delphi 7 stieg die Anzahl der Handles nämlich nur bei erneutem Erzeugen der TClient-Klasse aber nicht nach den Verbdindungsversuchen.

[Zacherl]

Zitat:

Zitat von Union (Beitrag 1224803)

Wie hast Du es jetzt konkret gelöst? Bei meinen Tests mit WinXP und Delphi 7 stieg die Anzahl der Handles nämlich nur bei erneutem Erzeugen der TClient-Klasse aber nicht nach den Verbdindungsversuchen.

Ich vermute mal, er verwendet jetzt die blocking Sockets. Vielleicht handelt es sich um einen Fehler in der RTL implementation der TClientSocket Klasse, der sich erst in späteren Delphi Versionen eingeschlichen hat. Ich habe in meiner Testanwendung die Socket Instanz nicht neu erstellt und dennoch wurden die Handles geleaked. Nichtmal nach dem abschließenden Freigeben der Komponente wurden die Handles wieder geschlossen.

[Union]

Es gibt nur wenige Änderungen zwischen D7 und XE4 in den ScktComp, bis auf die allfälligen Unicode-Umstellungen und Namespaces:

• Es gibt ein overload von Close. Vielleicht sollte man in diesem Fall dann diesen verwenden, obwohl davor gewarnt wird. Der sorgt nämlich für das "Search und Destroy" des Handles.
• Bei ReceiveBuf wird jetzt die Count-Var erhöht falls der Puffer inzwischen mehr Daten enthält als vermutet bzw. übergeben.
• Im Accept werden EAbort-Exceptions stummgeschaltet

[1aa]

Ich verwende jetzt blocking Sockets und es funkt. soweit auch alles, keine Memory Leak :-D

Aber eine andere Sache ist mir jetzt auf gefallen seit ich blocking Sockets verwende habe ich probleme dateien zu übertragen :


Empfang:

Delphi-Quellcode:

procedure TClient.DateiDownload(Socket: TCustomWinSocket);
var zielDatei: TFileStream;
    nSocketStream : TWinSocketStream;
    nReceived: Integer;
    Buffer: array [0..9999] of Char;
begin
 zielDatei := TFileStream.Create('neu.txt', fmCreate);
 try
   bDateiEmpfang := True;
   nSocketStream := TWinSocketStream.Create(Socket,5000);
   try
    while bDateiEmpfang do
     begin
         nReceived := nSocketStream.Read(Buffer, sizeof(Buffer));
         if nReceived <= 0
           then Break
           else
             zielDatei.WriteBuffer(Buffer, nReceived);
       Sleep(1);
     end;
   finally
     nSocketStream.Free;
   end;  
  zielDatei.Position := 0;
  bDateiEmpfang := false;
 finally
   zielDatei.Free;
 end;
end;

Es scheint nicht alle daten zu übertragen.....

Senden:

Delphi-Quellcode:

Socket.SendStream(TFileStream.Create('neu.txt', fmOpenRead or fmShareDenyWrite))

[1aa]

Edit : OK hat sich geklärt hatte in einer übergeordnenen Procedure einen Tip fehler... Funktioniert alles

Danke noch mal an alle die mir geholfen haben!