Detecting over-Releasing on COM objects

  • Artykuł

I am in Refcount Hell right now, trying to fix a new chunk of our codebase for COM refcounting issues. Debugging missing AddRefs consumes most of my time, and I might write about that one day, but yesterday I managed to over-Release an object and of course I crashed. Finding over-Releases is trivial by comparison:

Assuming you can determine the instance of your object that will be over-released, just set a 4-byte data breakpoint on that pointer value. When the object gets over-released, and its destructor called (by "delete this") the debugger will stop right at that point. This happens because a destructor will overwrite the vtable address with its base class, firing the data breakpoint.

(This assumes you are using some inheritance to get COM refcounting, such as ATL)

Comments

  • Anonymous
    July 21, 2006
    The comment has been removed
  • Anonymous
    July 22, 2006
    This worked for me because the penultimate call WAS the bad one. Agreed, this is not always the case.

    There is a much easier way Phaeron: Debugger Tracepoints. Set a tracepoint on the offending AddRef/Release funcs, and dump the callstack, this ptr, and refcount. You still have to manually tie them into matching pairs to find the errant call of course, and that takes the time. (Right now I have my object leaks down from over 22k to 19).