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 9 Jul 2007 17:38
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.




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


From: Joseph M. Newcomer on 10 Jul 2007 11:12
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 11:32
On Tue, 10 Jul 2007 09:45:46 -0500, "AliR \(VC++ MVP\)"
<AliR(a)online.nospam> wrote:

Thank you for you help. Perhaps "leak" is the wrong word because my
programs in debug mode never show a problem on exit. However the
Create method is consuming system memory that is not released back to
the system until the program closes.

The memory consumption is either shown as "Mem Usage" on the Task
Manager Processes page or by the following code:

PROCESS_MEMORY_COUNTERS pmc;
HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION
| PROCESS_VM_READ, FALSE, _getpid());
size_t retval = 0;
if (GetProcessMemoryInfo(hProcess, &pmc, sizeof(pmc)))
retval = pmc.WorkingSetSize;
CloseHandle(hProcess);

The memory used by my process continues to grow and grow indefinitely
even though I close and delete the socket. That seems intolerable,
whether or not it officially counts as a leak.

Maybe the Windows memory manager will eventually discover this and
recoup the memory, but how long will it take? All I know is that I
have a problem in the field when my program runs month after month and
this is the best clue I can generate on my test bed about what might
be the cause. I now have a version running in the field that logs its
memory usage once a day, but that will take days and weeks to analyze.
The problem is that the CAsyncSocket delete and recreate only occurs
when there are problems in the field, and they occur only
sporadically.

Incidentally, the memory consumption occurs both in debug and release
compilations and for both Unicode and simple char string (Character
Set not set) options. I tested that because CAsyncSocket::Create uses
T2A_EX within CAsyncSocket::Bind and I wonder whether that might be
the problem.


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

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


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