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 12:08
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
From: r norman on 10 Jul 2007 12:20
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 12:45

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 12:45
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:01
See below...
On Tue, 10 Jul 2007 12:20:08 -0400, r norman <r_s_norman@_comcast.net> wrote:

>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.
****
There are several levels of memory management going on here: the low-level VirtualAlloc
level, the LocalAlloc/GlobalAlloc memory, malloc/free (which are used by new/delete) and
MFC and its internal data structures.
****
>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.
*****
Memory fragmentation is the real issue here; it has nothing to do with "robustness", which
is a metric for reliability. A highly-fragmented memory can still be robust, but there is
nothing can be done at the simplistic level to change fragmentation. It is true that the
current high-level allocator (malloc/free) tends to be lower-fragmentation, but one of the
reasons I try to avoid using MFC in services is the fact that there is no control at all
over fragmentation problems. However, VS.NET and beyond allow you to replug the MFC
allocator mechanism, or so I've read, but I've not written any services since its release
and therefore haven't investigated it.
*****
>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.
****
It is a real problem with C++ because there is no layer you can introduce transparently to
put your own manager that would allow compaction underneath it. But if you eliminate
compaction, you can do a number of things to reduce fragmentation, but they involve either
replacing the basic allocator (the rumored capability I have not investigated) or live
with MFC allocation for its internal objects but use your own allocator for the objects
you manipulate. As long as they are your own objects, it's a lot easier. For example,
you can keep a table of indirection pointers to locate the objects, but the objects
themselves can use either only anchored pointers or the pointers to your own indirection
table.

The simplest solution is to do all your allocations using your own allocator strategy. Use
only one size of object, the max of all objects. The effect here is that every object is
the same size so all holes are the same size, so there is no fragmentation.

Note that these are not related to the basic OS strategy, but to higher-level strategies,
and "robustness" is not at all the same as "non-fragmenting".

Memory management is one of the nightmares of long-term services, and fragmentation is the
worst problem you can have after leaks. I've done a number of long-term services, and I
would say that the major effort I invested was in avoiding memory fragmentation. The
issue is not the nature of the basic allocator, but the fact that allocators are based on
certain models that do not necessarily provide the best support for long-term
applications.
joe

*****
>
>
>
>
>
>>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.