memory leak using string
Wolfgang Schmidt
I got some strange memory leaks using the STL string in MS Visual C++ 5.0
SP3.
I have just defined a class model that has some classes with attributes of
type string.
There is definetly no string allocation using the new operator. There is
even no implementation
at all in the class model.
nevertheless i get 2 messages of memory leaks in the VC 5.0 debugger. Using
Bounds Checker
i even get more memory leaks.
This seems very strange to me.
Is there anybody having a explanation to that ?
thanks for your time
wolfgang
Doug Harrison
It's probably normal, but you still need to find out what is causing the
leaks. For example:
p = new char[100];
Assuming p's data is intended to exist throughout the program's execution, I
wouldn't consider it a bug if the program never explicitly deletes p,
because the OS will reclaim the memory when the program ends. However, the
heap checkers will report it as a leak, and while it's a genuine leak, it
doesn't really indicate a problem. Even if you're careful to delete
everything you've allocated, MFC can cause truly spurious leaks to be
reported, because for reasons I don't understand, it dumps leaks during its
termination, instead of waiting for the CRT to dump leaks during its
termination, following destruction of all static duration data and execution
of atexit blocks. For example, if you link dynamically as follows:
CRT
LibA (doesn't use MFC)
LibB (uses MFC)
Now, LibB and thus MFC terminate before LibA and the CRT, so when MFC dumps
leaks, it dumps allocations that are active in LibA and the CRT. The
solution to this problem is for LibA to link to MFC in debug builds, but
that doesn't help the CRT.
For example, I routinely observe a couple of leaks in MFC apps:
Detected memory leaks!
Dumping objects ->
{49} normal block at 0x007F1D50, 33 bytes long.
Data: < C ÍÍÍÍÍÍÍÍÍÍÍÍÍ> 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{48} normal block at 0x007F1DA0, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
When I set an allocation breakpoint at {48}, I get the following
(abbreviated) stack trace, which indicates the "leak" originates in standard
library static data:
_heap_alloc_dbg(unsigned int 0x00000028, int 0x00000001, const char *
0x00000000, int 0x00000000) line 338
...
std::locale::_Init() line 55 + 7 bytes
...
std::basic_filebuf<char,std::char_traits<char>
>::basic_filebuf<char,std::char_traits<char> >(_iobuf * 0x1025a828 __iob)
line 71 + 36 bytes
std::ios_base::Init::Init() line 28 + 46 bytes
...
_CRT_INIT(void * 0x10480000, unsigned long 0x00000001, void * 0x0012ff30)
line 184 + 15 bytes
_DllMainCRTStartup(void * 0x10480000, unsigned long 0x00000001, void *
0x0012ff30) line 267 + 17 bytes
Tracing further, I find that the _CrtDumpMemoryLeaks call that produced the
leak report above originated in the destruction of an MFC global:
_CrtDumpMemoryLeaks() line 2057
_AFX_DEBUG_STATE::~_AFX_DEBUG_STATE() line 132
Then, when I force dumping of memory leaks in the CRT's PROCESS_DETACH
handler (see _CRTDLL_INIT() in crtlib.c), I get no memory leaks at all,
because it turns out the Standard C++ library static data was properly
destructed and the memory freed between the time MFC dumped leaks and the
time the CRT dumped leaks during its termination. So, MFC is definitely
causing spurious leak reports in this case. Unfortunately, I don't know of
any way to disable this MFC feature.
--
Doug Harrison
dHar...@worldnet.att.net
Wolfgang Schmidt
Doug Harrison wrote in message
<#3bxUwVU#GA....@uppssnewspub05.moswest.msn.net>...
Thanks for your kind replies!
my memory leaks are exactly of the same kind
here an example
Detected memory leaks!
Dumping objects ->
{50} normal block at 0x00BF0F30, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{49} normal block at 0x00BF0EE0, 40 bytes long.
Data: < :0 > EC 3A 30 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
youre explanation was very helpful
thanks a lot
Wolfgang