Detected memory leaks

2019-03-09 02:54发布

问题:

In my wxWidgets application, while running in debug mode i got this message in Output of Visual Studio 2010. The application ran fine, and i only saw this after closing it.

Detected memory leaks!

Dumping objects ->

{9554} normal block at 0x003CDCC0, 44 bytes long.
Data: < e n d > 20 C1 65 01 01 00 00 00 6E 00 00 00 9C CE 64 01

{9553} normal block at 0x003CDB58, 8 bytes long.

Data: < D e < > 44 BD 65 01 C0 DC 3C 00
{9552} normal block at 0x003CDC50, 48 bytes long.

Data: < e > A0 95 65 01 01 00 00 00 19 00 00 00 19 00 00 00

Object dump complete.

In my program i am not explicitly allocating memory, however the wxWidgets framework is. I have got such a message for first time, and don't know the exact cause of it.

How can i get rid of this memory leak?

回答1:

You just have to add the following lines at the beginning of your main function. Adding this flag, Visual Studio will break at the line that is creating the memory leak.

    _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
    _CrtSetBreakAlloc(9554);
    _CrtSetBreakAlloc(9553);
    _CrtSetBreakAlloc(9552);

Make sure you have the correct object normal block address because they might change and ensure you are compiling on _DEBUG.

See also: _CrtSetDbgFlag and _CrtSetBreakAlloc.



回答2:

  1. Never just 'assume' that your code is memory leak proof. Unless you are one of the programming demi-gods, no one is immune from possibly writing memory leaks.

  2. You could use a tool like bounds checker (From Microfocus) to help identify the memory leak because it will give you a callstack. The memory leak report you got from the debug CRT just tells you memory leaked at a particular address. A product like bounds checker will give you a callstack for that memory leak, along with lots of other goodies. There are other memory leak tools out there in the market, but I won't attempt to list them here.

  3. If you are sure the memory leak is due to 'wxWidgets', then perhaps you should inform the writers of that library and perhaps they will fix it (With suitable repro steps).



回答3:

Maybe some kinds of static instances are still allocated by the framework. Try to solve it with profiler like "devpartner".



回答4:

This wiki suggests adding the following to every source file you have, after all other header include's:

#ifdef __WXMSW__
    #include <wx/msw/msvcrt.h>      // redefines the new() operator 
#endif

This will result in leaks being reported when your program ends.

More specifically, make sure you call ->Destroy() on all objects you create using new (except maybe your top window).



回答5:

If the location of the leak reported by vs is same every time you could set a databreakpoint to see when this memory is being changed and hopefully figure out who is allocating this memory