Errors with Indy in threaded application !

Question

Hi,

I've got some memories leak related to TidHTTP when it's waiting for the response of a server after a GET and that the thread is being terminated.

Example :

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;

---

I stop the thread with this when the application close :

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

What should I do to solve the memories leaks ?

FastMM4 Log :

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

Thanks :)

Answer 1

You should call

aThread.WaitFor;

before destroying the thread. This makes sure that the thread properly terminates. Destroying the thread without terminating it probably causes an access violation in the execute method, which results in the memory leaks displayed by FastMM.

EDIT Considering the fact that the problem might be the blocking call in your execute method, you might want to set TIdHttp.ReadTimeOut to a reasonable time and check for thread termination in regular intervals.

Answer 2

Indy also produces two or three expected memory leaks, like the integer and the critical section. But they might or might not have been registered as expected. So I can't tell if these are the ones you see. If you would run your code 5 times, would you see more leakage than you are seeing now?

As for the WaitFor suggested by Smasher, to call before calling Free. This should not be needed, nor the cause of your problems, because if you check the destructor of TThread, you will see exactly that is already done.

Why you are getting an Access Violation in your leak report, I don't really know. However, you are calling Disconnect from outside of your thread, while the Indy component is in use in your thread. Don't do that, using the same non-thread-safe components from different threads is asking for trouble. This might cause your Access Violation leaking. Let the thread itself do ALL the calls to the Indy component.

Reducing the ReadTimeOut as suggested by Smasher is a good idea however to make sure your application doesn't block too long.