This is something that i found in another forum.. Hope this helps.....
-----------------------------------------------
It looks like TIdSMTP is leaking memory is created at run time in C++.
There are no known leaks in TIdSMTP (or any other Indy component, for that
matter).
Each click on the button will increase memory usage (as reported
by task manager).
You cannot use TaskManager to test for memory leaks. TM has no concept of
HOW your app uses memory, only HOW MUCH memory has been allocated to the
app. Keep in mind that Delphi/C++Builder's memory manager caches freed memory
for later reuse, the memory is not returned to the OS. If TM reports memory
usage is growing, that is not always an indication of a real leak. More
likely you are just fragmenting memory instead, causing the memory manager
to be unable to reuse memory it already has so it asks the OS for more memory.
To properly test for leaks, you have to let the memory manager report
the leaks to you, since only it knows what constitutes a real leak. Set
the global System::ReportMemoryLeaksOnShutdown variable (
http://docwiki.embarcadero.com/Librarie ... OnShutdown)
to true, or else install the full version of FastMM (
http://fastmm.sourceforge.net)
into your project and enable its leak reporting capabilities.
In addition, madExcept also report a memory leak in line 645 of
IdMessageClient.pas:
FMsgLineFold := TAB;
FMsgLineFold is a String member of the TIdMessageClient class.
In VCL, the only way that member can leak is if the TIdMessageClient destructor
is not being called. TIdSMTP derives from TIdMessageClient, but you are
destroying your TIdSMTP objects, so that could not be a leak. And every
place where Indy internally creates a TIdMessageClient object is protected
by a try/finally block to ensure the object is destroyed. So those cannot
be a leak, either. If MadExcept is claiming that FMsgLineFold is leaking
then it has to also be reporting that the owning TIdMessageClient is also
leaking, and it should be showing you the call stack where that object is
being created.
By chance, are you compiling this code in a FireMonkey mobile app? The code
you showed WOULD "leak" the objects (at least until the Form itself is destroyed)
because of ARC handling. The 'delete' operator does not destroy a TObject-derived
object under ARC, it merely decrements the object's reference count. You
are assigning an Owner to the TIdSMTP objects, and the Owner would have active
references to the TIdSMTP objects, thus your 'delete' would not have an effect.
To remove the active references, you would have to either:
1. not assign an Owner in the first place:
- Code: Select all
void __fastcall OnClick(Sender...)
{
TIdSMTP * SMTP;
int i;
for(i=0;i<100000;i++)
{
SMTP = new TIdSMTP(NULL);
delete SMTP;
}
}
2. remove the TIdSMTP objects from the Owner:
- Code: Select all
void __fastcall OnClick(Sender...)
{
TIdSMTP * SMTP;
int i;
for(i=0;i<100000;i++)
{
SMTP = new TIdSMTP(this);
this->RemoveComponent(SMTP);
delete SMTP;
}
}
----------------------------------------------
Corbin Gravely
