Fehler mit Indy in Threaded-Anwendung!

Question

Ich habe einige Erinnerungen bekommt Leck TidHTTP bezogen, wenn es für die Antwort eines Servers nach einem GET wartet und dass der Thread beendet wird.

Beispiel:

aThread = class(TThread) 
private  
  FidHTTP :TidHTTP;   
  FCommand :String;
public   
  procedure Execute(); override;   
  constructor Create(aCommand :String); override;
  procedure Disconnect;
end;

procedure aThread.Execute();   
  var response :String; 
begin   
  response := FidHTTP.Get(FCommand); 
end;

procedure aThread.Disconnect;
begin
  if ((FidHTTP <> nil) and (FidHTTP.Connected)) then FidHTTP.IOHandler.CloseGracefully;
end;

constructor aThread.Create(aCommand :String); override; 
begin   
  FCommand := aCommand;    
  inherited Create; 
end;

---

ich den Thread mit diesem stoppen, wenn die Anwendung schließen:

aThread.Disconnect;
aThread.Terminate;
aThread.Free;

Was soll ich tun, die Speicher Lecks zu lösen?

FastMM4 Log :

13 - 20 bytes: TIdThreadSafeInteger x 1
21 - 36 bytes: EAccessViolation x 1, TIdCriticalSection x 2
181 - 212 bytes: UnicodeString x 1

Danke:)

Answer 1

Sie sollten anrufen

aThread.WaitFor;

, bevor das Gewinde zu zerstören. Dies stellt sicher, dass der Faden richtig beendet. Die Zerstörung des Fadens ohne Abschluss es wahrscheinlich verursacht eine Zugriffsverletzung in der Execute-Methode, die Ergebnisse in den Speicherlecks durch FastMM angezeigt.

Bearbeiten In Anbetracht der Tatsache, dass das Problem der Blockierung Call-Methode in Ihrer ausführen könnte, Sie TIdHttp.ReadTimeOut zu einer angemessenen Frist setzen möchten und in regelmäßigen Abständen für die Faden Beendigung überprüfen.

Answer 2

Indy produziert auch zwei oder drei erwartete Speicherlecks, wie die ganze Zahl und dem kritischen Abschnitt. Aber sie könnte oder nicht registriert wurden, wie erwartet. So kann ich nicht sagen, ob diese sind diejenigen, die Sie sehen. Wenn Sie Ihren Code 5 mal laufen würde, würden Sie mehr Leckage zu sehen, als Sie jetzt sehen?

Wie für die WaitFor vorgeschlagen von Smasher, vor dem Aufruf kostenlos zu anrufen. Dies sollte nicht notwendig sein, noch die Ursache Ihrer Probleme, denn wenn man den destructor von TThread überprüfen, sehen Sie, genau das bereits getan.

Warum Sie eine Zugriffsverletzung in Ihrem Leck Bericht bekommen, ich weiß es nicht wirklich. Allerdings rufen Sie trennen von außerhalb des Threads, während die Indy-Komponente in dem Einsatz in Ihrem Thread ist. Tun Sie das nicht mit den gleichen nicht-Thread-sicheren Komponenten von verschiedenen Threads für Probleme bitten. Dies könnte Ihre Zugriffsverletzung undicht verursachen. Lassen Sie den Faden selbst in die Indy-Komponente alle Anrufe zu tun.

Die Reduzierung der Readtimeout wie Smasher vorgeschlagen ist eine gute Idee, aber sicherstellen, dass Ihre Anwendung nicht zu lange blockiert.