|Subject:||Re: Possible mem leak?|
|Posted by:||Remy Lebeau (TeamB) (email@example.com)|
|Date:||Wed, 24 May 2006|
"Goran" <gor…@k-info.hr> wrote in message
> IDFtp is using IDThread.
TIdFTP does not use TIdThread. The uses clause does include the IdThread
unit, though. Since TIdFTP does not use TIdThread, IdThread shold be
removed from the uses clause.
> After executing code that even do not use INDY components,
> FastMM reports memleak
The leak you are referring to is an intentional one. The object in question
is a global TIdThreadSafeInteger that is allocated in the initialization
section of IdThread.pas, but is intentionally not freed by default in the
finalization section. To free the TIdThreadSafeInteger, you have to
recompile Indy with IDFREEONFINAL defined.
The reason for this leak is because Delphi's finalization order of units is
not reliable in all versions. Indy has had problems with units being
finalized in the wrong order, so units that access each other's global
objects try to access objects that have already been freed. There is a
similar leak in IdStack.pas for a global TIdCriticalSection for the same
reason. There is a comment in the source code of IdStack.pas that explains
> Also, IDFtp.UseTLS is declared as utNoTLSSupport. Why do I have
> to link IdExplicitTLSClientServerBase ?
Because that is where the UseTLS property is inherited from, and where
utNoTLSSupport is declared. A lot of Indy components support TLS, so the
common logic was abstracted into TIdExplicitTLSClient/Server base classes
that the higher-level components derive from.
Possible mem leak? posted by Goran on Wed, 24 May 2006