Memory leak in IdComponent indy
tom
My program has used TidtcpServer Componet, when i had checked the Memory
leak
situation of the program ,found that there is a memory leak in the unit
IdComponent. The CrticalSetion created in the initialization seciton has
not
been free, there are some remarks following in unit IdComponet,
initialization
GStackCriticalSection := TCriticalSection.Create;
finalization
// Dont Free. If shutdown is from another Init section, it can cause GPF
when stack
// tries to access it. App will kill it off anyways, so just let it leak
// FreeAndNil(GStackCriticalSection);
i am confused of these remarks, any one explain it may be helpful to me ,
i hope that i have express it clearly, thanks in advance !
René Allan Larsen
>
> Hello everyone!
>
> My program has used TidtcpServer Componet, when i had checked the Memory
> leak
> situation of the program ,found that there is a memory leak in the unit
> IdComponent. The CrticalSetion created in the initialization seciton has
> not
> been free, there are some remarks following in unit IdComponet,
A memory leak because you don't free something in the "finalization" part
that was created in the "initialization" part, is IMHO not really a memory
leak. Windows frees all memory allocated by your program, when the program
shuts down.
> initialization
> GStackCriticalSection := TCriticalSection.Create;
> finalization
> // Dont Free. If shutdown is from another Init section, it can cause GPF
> when stack
> // tries to access it. App will kill it off anyways, so just let it leak
> // FreeAndNil(GStackCriticalSection);
>
> i am confused of these remarks, any one explain it may be helpful to me ,
> i hope that i have express it clearly, thanks in advance !
The remarks simply says that the order in which different units are
initialized (and finalized) is important. I suspect that the FreeAndNil was
commented out because someone suddenly started getting GPF's when stopping a
program.
Would you rather prefer that your program after the last compilation
suddenly began to crash?
Regards, René
Finn Tolderlund
"René Allan Larsen" <rene....@spamfilter.dk> skrev i en meddelelse
news:VA.0000006...@spamfilter.dk...
> A memory leak because you don't free something in the "finalization" part
> that was created in the "initialization" part, is IMHO not really a memory
> leak. Windows frees all memory allocated by your program, when the program
> shuts down.
If someone uses that code in a DLL which is dynamically loaded/unloaded then
that leak suddenly becomes important.
--
Finn Tolderlund
Remy Lebeau (TeamB)
"René Allan Larsen" <rene....@spamfilter.dk> wrote in message
news:VA.0000006...@spamfilter.dk...
> A memory leak because you don't free something in the "finalization"
> part that was created in the "initialization" part, is IMHO not really a
> memory leak. Windows frees all memory allocated by your program,
> when the program shuts down.
That depends on the version of Windows and the type of memory involved. Not
all types of memory are automatically reclaimed under all versions of
Windows. In this particular case, it is a Kernel object, so Windows should
reclaim it.
Gambit
Chad Z. Hower aka Kudzu
news:40b5...@newsgroups.borland.com:
> Not all types of memory are automatically reclaimed under all versions
> of Windows. In this particular case, it is a Kernel object, so Windows
> should reclaim it.
99% of objects are cleaned up in Win32 as they are part of the process.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Is Indy useful to you? Send a postcard please!
http://www.hower.org/kudzu/indypost.html
Remy Lebeau (TeamB)
"Chad Z. Hower aka Kudzu" <cp...@hower.org> wrote in message
news:Xns94F65BF...@127.0.0.1...
> 99% of objects are cleaned up in Win32 as they are part of the process.
System objects, perhaps. Not heap memory, for instance.
Gambit
tom jin
>
> System objects, perhaps. Not heap memory, for instance.
>
>
> Gambit
>
i have record all allocate and free memory behavior from application
initilize to application terminater, found that 35 bytes memory had been
allocted in idComponet unit
has not been freed when terminate the program . So i thought that it is
memory leak.
Remy Lebeau (TeamB)
"tom jin" <ji...@longs.cc> wrote in message
news:40b7...@newsgroups.borland.com...
> i have record all allocate and free memory behavior
How exactly?
> found that 35 bytes memory had been allocted in idComponet
> unit has not been freed when terminate the program . So i
> thought that it is memory leak.
That depends on what kind of memory it is to begin with, and who allocated
it.
Gambit
tom jin
> That depends on what kind of memory it is to begin with, and who allocated
> it.
I am a beginner on windows program and have not known much more knowledge
needed,
could you list the kinds of memory and their charactoristics, that would
direct me
to read the right book or materrial about this topic .
finally sorry for poor English :-P
Chad Z. Hower aka Kudzu
>> 99% of objects are cleaned up in Win32 as they are part of the process.
>
> System objects, perhaps. Not heap memory, for instance.
The heap is part of the process too just as the stack is. Only a few system
global tybe objects dont get freed.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Want to keep up to date with Indy?
Join Indy News - it free!