Finding Memory Leaks using Divide and conquer

I just created/used this technique to find an elusive 8 byte memory leak in < 1 hr...

Let's take a look at the evolution of the technique:

The debugger is reporting a memory dump of {1510} normal block at 0x0B0774E0, 8 bytes long.

I began by looking at a suspected class and its members
Note: I set Watches to record memory locations to record addresses of the actual objects to be compared against the leak after application exit

Round 1 --
In object suspected to contain the leak:
+ this 0x0b080148 { ...}
leak @ 0xB0804E8 (okay looks like the leak is after this object)
+ m_AmpHandle 0x0b080280

+ m_CaptureDeviceName 0x0b080650
+ m_VolumeController 0x0b080640

Round 2 --
I tried to narrow down to member objects in the suspected class
+ m_OSVersion 0x0b0785fc
{1510} normal block at 0x0B0774E0, 8 bytes long.

Round 3 --
In object suspected to contain the leak:
+ this 0x0b077638
+ m_RenderDeviceName 0x0b0776c8
+ m_CaptureDeviceName 0x0b077648
{1498} normal block at 0x0B0774E0, 8 bytes long. (hmmm, maybe the leak is not in this object at all...)

Round 4 --
+ m_OSVersion 0x0b0785fc
+ m_AmpHandle 0x0b077690
{1498} normal block at 0x0B077998, 8 bytes long. (hmmm, the leak is after this handle... where does that handle come from?)

Round 5 -- moved investigation up a level
+ m_AdaptableVolumeController 0x0b0775c8 }
+ m_RenderFilter 0x0b080288
{1558} normal block at 0x0B083568, 8 bytes long. (hey, look at that... the leak is right in between these two, which probably means its in the renderfilter object)
+ m_CaptureFilter 0x0b0835b0
+ m_OSVersion 0x0b0785fc
+ m_AmpHandle 0x0b0776d8


Round 6 -- focusing investigation in the renderfilter
+ m_RenderFilter 0x0b0801b8
+ m_DolbyModel 0x0b080e70
+ m_GainModel 0x0b080228
+ m_ChannelAttenuationModel 0x0b080280
+ m_EAdvEqModel 0x0b0774e0
+ m_SimpleEqModel 0x0b0775f8
+ m_AdvEqModel 0x0b077698
+ m_AttMeasModel 0x0b0802d8
{1498} normal block at 0x0B0802D8, 8 bytes long. (HEY HEY! we have a match!)
+ m_CaptureFilter 0x0b077738


And it turned out that this pointer was not being deleted.

So with just standard tools, VisualStudio and Notepad you can quickly narrow down a memory leak.
Yes, one could just look for new/delete matches, but with a code base of a certain size this visual verification can be difficult to conduct.



















Divide and conquer algorithm - Wikipedia, the free encyclopedia: "divide and conquer (D&C)"