I recently dealt with a large memory leak that turned out to be a delicate reference count issue. It is a common debugging scenario, and I’ll be sharing here some suggestions about it.

First I had to isolate the leaking object. It so happened the leaking allocation was in a consistent place so setting_crtBreakAlloc was enough. Seeing that it was ref-counted, my first thought was to break on AddRef and Release, with a condition for ‘this’ to equal the object address:

This actually works, but is excruciatingly slow since any sane AddRef is templated and instantiated many times. A better method is to set a data breakpoint on the reference count itself:

(God knows why this BP is split into children. I guess I was quick to say this is resolved in VS2010).

If the debugged scenario is non trivial, you might prefer to not actually break, but rather dump stacks on any ref count change and match the stacks offline. Enter tracepoints:

Can we enhance the stack dumps with the current refcount value? You bet. Just add the contents of (‘{ }’) the refcount (0x037a17a4 in this case):

In my case the dumps held ~3000 stacks, so manual analysis was out of the question. Now I knew the leak was limited to a certain usage scenario, so I took trace dumps in leaking and non-leaking scenarios, saved both to files, diff’ed them – and the offending stack popped out immediately.

Next time – a similar trick in a different scenario.