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 13:07
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?

>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
From: r norman on 10 Jul 2007 13:08
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.

>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 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!
>
>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
>>>
>
From: Joseph M. Newcomer on 10 Jul 2007 13:12
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: AliR (VC++ MVP) on 10 Jul 2007 13:14
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


From: AliR (VC++ MVP) on 10 Jul 2007 13:24
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
>
>


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.