I don't have access or Orcas right now. Joe can you test the example in
Accoding to this post from 2005:
http://www.codeguru.com/forum/archive/index.php/t-353944.html
Microsoft has confirmed the memory leak.
08-25-2005, 11:40 AM
I contacted Microsoft via their MSDN forums and notified them of the
memory problems I am having with CAsyncSockets and CSockets. One of the
Microsoft people who monitor the forums wrote that he has verified the
memory allocation problems using C++ 6.0 and MFC 4.2 on a Windows XP
Pro system (that in addition to it occurring on XP Home Edition).
So, the problem is now verified by Microsoft.
It is NOT something that I was doing wrong. There actually is a memory
problem with CAsyncSockets and CSockets (beyond the other problems that
have been identified by others).
AliR.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:lid793dh8nso6a07fpmql60g30gp5bmb81@4ax.com...
On Tue, 10 Jul 2007 10:33:26 -0500, "AliR \(VC++ MVP\)"
<AliR@online.nospam> wrote:
As far as the memory being returned, it will eventually, when the system
thinks that the program won't need it anymore.
****
But that's what 'delete' is saying...
****
With the example I posted, before the loop my sample app is using 3676K
of
memory after the loop the program is using 4024K of memory but there is
no
memory leak.
****
Based on what diagnostic tool? Memory used as memory footprint is not
the same as memory
used because it is allocated; in fact, there is no mechanism I am aware
of for the program
to release memory to the operating system once it has been granted to the
heap.
*****
As far as Create not being reentrant goes, I am not really sure what
could
be causing that. There are some many possibilities as to why it doesn't
work the way he wants it. Is Close being called before the next call to
Create? Is the socket being passed from one thread to another? Maybe
even
a corrupted install of Visual Studio.
*****
Most of MFC is thread-safe insofar as its own internal data structures;
what is not
thread-safe is the user-visible structures. So if I access a CString or
CArray without
synchronization, that is an error. But if MFC uses a CArray, CMap, etc.
internally,
either it is used exclusively by one thread or it is handled with
synchronization. That's
what worries me: that there is some unprotected structure inside MFC that
we should not be
depending on without external synchronization.
joe
*****
I think that the OP should try and recreate the problem with one socket
in
the main thread. And go from there.
AliR.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:2c87935kti783rkaf53n5d28th16khebq9@4ax.com...
I would have thought it *would* be returned.
I'm also concerned about the concurrency problem, because I've not seen
that particular
problem in MFC before. I'm wondering if there is some storage damage
that
is causing both
apparent problems.
joe
On Tue, 10 Jul 2007 09:45:46 -0500, "AliR \(VC++ MVP\)"
<AliR@online.nospam> wrote:
I couldn't find a memory leak. What you are most likely seeing is
windows
memory managment doing its work. The Create method is creating a
socket
object, when when it's freed the memory is not given back to the system
right away.
(I used this method to detect a leak)
// Declare the variables needed
#ifdef _DEBUG
CMemoryState oldMemState, newMemState, diffMemState;
oldMemState.Checkpoint();
#endif
for (int i=0; i<10; ++i)
{
CAsyncSocket *pAS = new CAsyncSocket;
pAS->Create();
pAS->Close();
delete pAS;
}
#ifdef _DEBUG
newMemState.Checkpoint();
if( diffMemState.Difference( oldMemState, newMemState ) )
{
TRACE( "Memory leaked!\n" );
}
#endif
AliR.
"r norman" <r_s_norman@_comcast.net> wrote in message
news:2895939efidggi556s7fbje0euhm2jd2d0@4ax.com...
I have traced a memory leak problem to CAsyncSocket::Create(). Is
this a known problem? Is there a workaround/solution/fix? Here is
sample code:
for (int i=0; i<m_nReopenCount; ++i) {
CAsyncSocket *pAS = new CAsyncSocket;
pAS->Create();
pAS->Close();
delete pAS;
}
Running this 1000 times uses up 1200 KBytes of memory, or just over 1
KByte per call. Commenting out the Create() leaves memory clean.
(And
please don't complain about my bracketing style -- I like it.)
I have Visual Studio 2005 Professional version 8.0.
Incidentally, I also discovered that the call to Create() is not
re-entrant. My application involves connecting to some 10 to 20
external devices and my normal code creates a CWinThread to support
each socket, where the socket is created and destroyed only within
the thread routine. Creating all the threads and starting them up
simultaneously meant having multiple instances of
CAsyncSocket::Create() being called at the same time, crashing my
system (memory access faults). That one I found and fixed with
sentries. Now I am left with the memory leak.
The problem is that I have an rather intricate communication protocol
system all self contained so that adding a new hardware device simply
means creating a new instance of the whole works. It runs fine until
the external hardware goes haywire, in which case I destruct the
whole
instance and start a new one which breaks and reconnects the socket
with a clean start and, most of the time, results in a good
connection; the external device resets itself through the disconnect.
One faulty device, though, generated thousand upon thousand of
disconnects over a number of days and, after a few hundred thousand
of
these I my own system crashed due, I have now found out, to a lack of
memory caused by this leak.
My application must run essentially as an embedded system, unattended
week after week, month after month so I cannot tolerate a memory
leak.
Does anybody know about this? Is there a simple clean way to force a
socket disconnection on a CAsyncSocket and then reconnect? My
application is the connect() end of the socket, not the listen() end.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm