Question

The situation:

I see around + 120kbytes increase when closing the class,
so when i close the clas few times memory increases – and i need to find out what is causing this.

Just looking for any good tip or trick of how to find out what is not freed/released with vstudio 2010 – any ideas?

Here’s more clearly what i do ( very simplified )

class cSomeClass
{
 cSomeClass();
 ~cSomeClass();
  int Initialize();
  void Deinitialize();
}


cSomeClass cCamera;

    main()
    {
     Sleep(10000);

    // Do Init / Deinit to find out if we are freeing the memory
    while(1)
    {
      // Init camera
      if(cCamera.Initialize()==0)
      {
       // Rest for a while
       Sleep(1500);
       cCamera.Deinitialize();
       // Rest for a while
       Sleep(1500);
      }

    }
}

I just did a small application to init / deinit the class object to see
in the ‘task manager’ if my memory for this application is returning to it’s starting value – but it is not, it keeps incrementing every time i initialize the cSomeClass – so i believe i have something that is initialized but not freed in Deinitialize.

Update:

I don’t think it is a simple memory growth, when application is launched it stabilizes itself after 10 seconds to let’s say : 1MB of ram then when while(1) kicks in every Initialize i call i get +120kBytes in overall application memory ( checked in task manager ).

Update:

Thanks to Chad – got it sniffed with

_CrtDumpMemoryLeaks

Detected memory leaks!
Dumping objects ->
{76} normal block at 0x003F4BC8, 32 bytes long.
 Data: <Logitech QuickCa> 4C 6F 67 69 74 65 63 68 20 51 75 69 63 6B 43 61 
{75} normal block at 0x003F4B80, 8 bytes long.
 Data: < K?     > 20 4B 3F 00 00 00 00 00 
{74} normal block at 0x003F4B20, 32 bytes long.
 Data: < K?  K?         > 80 4B 3F 00 C8 4B 3F 00 CD CD CD CD CD CD CD CD 
{70} normal block at 0x003F4A30, 8 bytes long.
 Data: < )i     > 0C 29 69 00 00 00 00 00 
Object dump complete.

Answer 1

The most straight forward method is to use the Windows API functions for memory usage tracking, like _CrtDumpMemoryLeaks.

Using this in conjunction with _CrtMemCheckpoint can prove to be vital when tracking down stubborn leaks.

If you are using MFC, you can optionally define DEBUG_NEW, which adds additional tracking to the global new/delete operators, giving you file and line numbers for each allocation that leaks, this can be extremely helpful as well, but it doesn’t work with some implementations of new (std::nothrow, for instance).