Prev: loading xml file in winme
Next: MFC/MDI App fails with "An invalid argument was encountered." on click File menu item.
From: r norman on 10 Jul 2007 14:25
On Tue, 10 Jul 2007 13:12:46 -0400, Joseph M. Newcomer
<newcomer(a)flounder.com> wrote:

What is to be done? Ali R's citation shows Microsoft has known about
the memory issue for some two years, now, at least in C++ 6.0 and MFC
4.2. Why is it still present in C++ 8.0 and MFC -- what is it now,
8?. Not only is it present, there is no warning about it in the
documentation as a "feature." So how would reporting this as a bug
make any difference?

>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.
> joe
>
>On Tue, 10 Jul 2007 12:08:44 -0400, r norman <r_s_norman@_comcast.net> wrote:
>
>>On Tue, 10 Jul 2007 11:12:12 -0400, Joseph M. Newcomer
>><newcomer(a)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(a)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(a)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(a)flounder.com
>>>Web: http://www.flounder.com
>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
>Joseph M. Newcomer [MVP]
>email: newcomer(a)flounder.com
>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 10 Jul 2007 16:01
See below...
On Tue, 10 Jul 2007 13:07:32 -0400, r norman <r_s_norman@_comcast.net> wrote:

>On Tue, 10 Jul 2007 12:45:25 -0400, Joseph M. Newcomer
><newcomer(a)flounder.com> wrote:
>
>I can accept that memory allocated to my process won't be returned to
>the system. But when my process is done with it and needs more,
>shouldn't the memory manager take from my own internal unused heap and
>not ask the system for more? Where does it end? When the system is
>exhausted?
****
It should, assuming it can find the space. But the space you freed up may be broken up
into smaller pieces so that by the time you get back to asking for it, there isn't a piece
big enough to satisfy your request. This is what the "memory fragmentation" problem is
all about, and which is why you can spend weeks figuring out how to fix it. This is *not*
an "error" in the allocator; it is doing exactly what it is supposed to do. It has
nothing to do with the robustness of the algorithms, or their correctness; it has to do
with whether or not your allocation patterns generate situations guaranteed to be pessimal
for a specific design of an allocator (by the way, like paging algorithms, tell me how
your allocator works and I can create a situation that will stress it to beyond its
breaking point).

And yes, it ends when you hit the 2GB limit for your process, or the system runs out of
virtual memory to hold your process, whichever comes first.
joe

****
>
>>On Tue, 10 Jul 2007 10:33:26 -0500, "AliR \(VC++ MVP\)" <AliR(a)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(a)flounder.com> wrote in message
>>>news:2c87935kti783rkaf53n5d28th16khebq9(a)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(a)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(a)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(a)flounder.com
>>>> Web: http://www.flounder.com
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>>Joseph M. Newcomer [MVP]
>>email: newcomer(a)flounder.com
>>Web: http://www.flounder.com
>>MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 10 Jul 2007 16:02
I have no copy of Orcas.

Ouch! This is a serious issue then, and I agree: why has it not been fixed?
joe

On Tue, 10 Jul 2007 12:24:37 -0500, "AliR \(VC++ MVP\)" <AliR(a)online.nospam> wrote:

>I don't have access or Orcas right now. Joe can you test the example in
>orcas to see if the problem is there too?
>
>AliR.
>
>"AliR (VC++ MVP)" <AliR(a)online.nospam> wrote in message
>news:2bPki.4747$rL1.2877(a)newssvr19.news.prodigy.net...
>> 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(a)flounder.com> wrote in message
>> news:lid793dh8nso6a07fpmql60g30gp5bmb81(a)4ax.com...
>>>
>>> On Tue, 10 Jul 2007 10:33:26 -0500, "AliR \(VC++ MVP\)"
>>> <AliR(a)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(a)flounder.com> wrote in message
>>>>news:2c87935kti783rkaf53n5d28th16khebq9(a)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(a)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(a)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(a)flounder.com
>>>>> Web: http://www.flounder.com
>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>>
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>
>>
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 10 Jul 2007 16:12
See below...
On Tue, 10 Jul 2007 13:08:46 -0400, r norman <r_s_norman@_comcast.net> wrote:

>On Tue, 10 Jul 2007 11:45:00 -0500, "AliR \(VC++ MVP\)"
><AliR(a)online.nospam> wrote:
>
>Incidentally, the first time I create and delete CAsyncSocket, it uses
>312K of system memory. After that it uses only 1K each time. I am
>not concerned about one-time memory usage, only about continuous
>nibbles eating away system memory.
****
The 312K is probably loading the WInsock DLL and support and creating the initial
structures.

Note that if the leakage is in WinSock, no change you make about managing low-level
sockets (I'm reading these out-of-order) is going to fix your problem. This is why it is
essential to understand where the lossage is happening.
****
>
>>hummm, I ran a sample that created 1000 sockets and closed them. The memory
>>usage went up 1 Meg, I watched it for an hour to see when the memory would
>>be released, it didn't.
*****
I'm not surprised. If the memory is being lost, it is being lost, and nothing is going to
magically make it be released at some indefinite future time.
*****
>>
>>I put a call to WSACleanup right after the loop and no more increase in
>>memory. Seems like whatever memory is allocated by the sockets gets cleaned
>>up on after WSACleanup is called!
*****
Don't confuse the removal of the DLL and its basic data structures with the freeing of
other memory. Again, key here is to see where the storage is being lost. If it is being
lost in the WinSock library because you are using asynchronous sockets, you are screwed.
If it is being lost in MFC, there is a slight chance you might be able to work around it.
joe
*****
>>
>>Ok I'm baffled.
>>
>>AliR.
>>
>>"r norman" <r_s_norman@_comcast.net> wrote in message
>>news:cpb793pdjqar537ms5nctjavvbqmumgo76(a)4ax.com...
>>> On Tue, 10 Jul 2007 10:33:26 -0500, "AliR \(VC++ MVP\)"
>>> <AliR(a)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.
>>>>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.
>>>>
>>>>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.
>>>>
>>>>I think that the OP should try and recreate the problem with one socket in
>>>>the main thread. And go from there.
>>>
>>> I responded to Joe's post about the concurrency problem and explained
>>> what I was doing there. It was multiple instances of CAsyncSocket
>>> that was the problem, not successive Creates on the same instance or
>>> sockets shared between threads. And I found a workaround by
>>> serializing the calls to Create so I left it at that.
>>>
>>> I still worry about Windows memory management and whether it is solid
>>> enough to support embedded programs that run continuously for month
>>> after month. I know for a fact that older versions of Visual C
>>> programs (version 3.0 or 4.0 if my memory serves me well) running on
>>> 16 bit MS-DOS failed miserably -- memory became so fragmented that it
>>> was unusable even if the total available byte count was maintained. At
>>> that time, I had to go to a commercial third party memory manager. I
>>> only reluctantly migrated from C to C++ because of my fears of the
>>> object oriented code's proclivity to create and delete objects at
>>> will, thereby stressing the memory manager to its limits. My roots
>>> are in 8 bit embedded systems with really severe memory constraints
>>> and I still have a probably unfounded fear of that problem.
>>>
>>>
>>>
>>>
>>>
>>>>AliR.
>>>>
>>>>
>>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>>>>news:2c87935kti783rkaf53n5d28th16khebq9(a)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(a)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(a)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(a)flounder.com
>>>>> Web: http://www.flounder.com
>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>>
>>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Michael K. O'Neill on 10 Jul 2007 16:45

"r norman" <r_s_norman@_comcast.net> wrote in message
news:2895939efidggi556s7fbje0euhm2jd2d0(a)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.)
>


This is a known problem, acknowledged by Microsoft.

Apparently, when using CAsyncSocket in a GUI app that also has XP visual
styles (themes), there is a memory leak. The problem seems to be
OS-dependent, and it might exist only under XP (running themes). It did not
manifest itself under Win 2000, and it might be gone now from Vista.

For one report, see "CSocket Consuming Memory Uncontrollably" at
http://www.codeguru.com/forum/showthread.php?t=353944 . I am fairly certain
that this is the same problem that you are seeing, since this report also
includes the exact same number for the amount of leaked memory (i.e., 1200
bytes per call to Create()).

There is a parallel posting in the newsgroups at "HELP!! CSocket and
CAsyncSocket Consumes Memory Uncontrollably" in the
microsoft.public.win32.programmer.networks newsgroup, at
http://groups.google.com/group/microsoft.public.win32.programmer.networks/browse_frm/thread/8490cdb5c4f18c76/b87332dbee0cb54c?tvc=1

The "solution", if you can call it that, is to disable themes. See
"CAsynCSocket Memory Leak Fix" at
http://www.codeguru.com/forum/showthread.php?t=370761

Mike


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: loading xml file in winme
Next: MFC/MDI App fails with "An invalid argument was encountered." on click File menu item.