Memory Leak? Need help!!!

[fang...@my-dejanews.com]

I am working on a multithreaded program. The object dumping shows memory
leaks. Here is the dumping result:

Detected memory leaks!
Dumping objects ->
strcore.cpp(76) : {69} normal block at 0x00411BB0, 65 bytes long.
Data: < 4 4 CTMT> 01 00 00 00 34 00 00 00 34 00 00 00 43 54 4D 54
strcore.cpp(76) : {59} normal block at 0x00411810, 47 bytes long.
Data: < " (208> 01 00 00 00 05 00 00 00 22 00 00 00 28 32 30 38

It seems to me that CString is leaking memeory. I deallocated all memory
and CString is not supposed to leak memory. Does anyone have any idea about
this? In my program, I used CString a lot as local varibles. I can't figure
out which one is leaking memory.

I really appricate any help.

Thanks

Fang

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

[Doug Harrison]

fang...@my-dejanews.com wrote:

>I am working on a multithreaded program. The object dumping shows memory
>leaks. Here is the dumping result:
>
>Detected memory leaks!
>Dumping objects ->
>strcore.cpp(76) : {69} normal block at 0x00411BB0, 65 bytes long.
> Data: < 4 4 CTMT> 01 00 00 00 34 00 00 00 34 00 00 00 43 54 4D 54
>strcore.cpp(76) : {59} normal block at 0x00411810, 47 bytes long.
> Data: < " (208> 01 00 00 00 05 00 00 00 22 00 00 00 28 32 30 38
>
> It seems to me that CString is leaking memeory. I deallocated all memory
>and CString is not supposed to leak memory. Does anyone have any idea about
>this? In my program, I used CString a lot as local varibles. I can't figure
>out which one is leaking memory.

If the allocation numbers are consistent from run to run, set an allocation
breakpoint at {59}. (See KB article Q151585 for details.) Then look in the
stack window to determine the source of the leak.

--
Doug Harrison
dHar...@worldnet.att.net

[Bryan Donaldson]

If you have any global CStrings, they will usually be reported as leaks. It
appears that the destructors for global items don't get called until after
the leak detection processing is run. This probably because the leak
detection processing uses global data (catch-22).

We solved it by having an explicit clean up function that emptied all global
CStrings.

[Doug Harrison]

Bryan Donaldson wrote:

>If you have any global CStrings, they will usually be reported as leaks. It
>appears that the destructors for global items don't get called until after
>the leak detection processing is run. This probably because the leak
>detection processing uses global data (catch-22).

MFC does prematurely report leaks during destruction of one of its globals,
afxDebugState, an instance of _AFX_DEBUG_STATE, instead of waiting for the
CRT to dump leaks following destruction of all static data and running of
atexit functions. I regularly see this when using the C++ draft standard
library and the MFC DLL, or in general, when using a mixture of DLLs, some
of which use MFC, and some of which don't. You can avoid this problem by
forcing the debug versions of the non-MFC DLLs to link to MFC, say, by
referencing an MFC global:

#ifdef _DEBUG

#define _AFXDLL
#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
#include <afx.h>

// Force linking to MFC.
static BOOL x = afxTraceEnabled;

#endif

This causes MFC's static data to be initialized before and destroyed after
the DLL's static data. I can't think of any reason why MFC should dump leaks
itself, rather than wait for the CRT to dump leaks at the proper time.

I'm not sure how global CStrings could elicit spurious leak reports. MFC's
afxDebugState variable, which is responsible for the premature leak reports,
is declared under #pragma init_seg(lib), so even if you're linking to MFC
statically, it should be initialized before any of your own globals, unless
maybe you're also using #pragma init_seg(lib|compiler).

--
Doug Harrison
dHar...@worldnet.att.net

[James Curran]

Doug Harrison wrote in message ...

>I regularly see this when using the C++ draft standard
>library

Ahem... It's not a "draft standard" anymore.

--
Truth,
James [MVP]
http://www.NJTheater.Com -and-
http://www.NJTheater.Com/JamesCurran

[Doug Harrison]

James Curran wrote:

>Doug Harrison wrote in message ...
>>I regularly see this when using the C++ draft standard
>>library
>
> Ahem... It's not a "draft standard" anymore.

Well, I know that. :) But I was referring to the C++ library supplied with
VC6, which was written against a draft, and which doesn't conform to the C++
Standard Library in a number of significant ways. I don't know what else to
call it, and I don't want anyone to think I'm talking about <fstream.h> et.
al.

--
Doug Harrison
dHar...@worldnet.att.net

[Dan Evens]

In your debugger, open the file strcore.cpp. Go to line 76 as
indicated.
Put a breakpoint there. Find out where in your code this is being
called.
When it hits the breakpoint, use the call stack view window to find out
where in your code it has been called. Find out which one is not getting
freed up after.