Part of this worries me, because a lot of us depend on the internal integrity of MFC in
such cases. So you may have located a serious bug in MFC; concurrency at this level
should not cause any malfunction. If it does, it would be a bug.
On Tue, 10 Jul 2007 11:12:12 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
The concurrency problem was over a year ago so I am speaking only from
memory and my comments I noted in my code at the time. I created
sixteen instances of a CWinThread derived class in quick succession,
each of which creates its own instance of a CAsyncSocket and calls
Create. That produces a system "crash", a term which you (Joe)
scolded me about at the time because it carries no diagnostic
information. It was, as I recall, a memory access error somewhere
within CAsyncSocket::Create but I don't now remember exactly where. It
showed behavior typical of a race or 'simultaneousness' problem: two
instances seemed to never have a problem, three or four showed a
problem sometimes, five or six almost always did and seven or more
always did. I solved the problem by protecting the call to Create so
that only one could execute at a time. Since the problem was solved,
I didn't concern myself with the far more serious problem of how such
a situation could continue to exist in the MFC code.
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]