Tracking memory leak

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.

---

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

---

I'm not sure exactly what you mean by "closing the class", but if you're able to run your code in Linux valgrind is always a great option to track memory leaks. Purify also works well in Windows but it's $$.

Another approach is to try to stop the problem up front: Use smart pointers instead of raw pointers.

Finally make sure that you're actually seeing a leak and not just a memory growth up to a certain plateau.