Non-psychic debugging: If somebody's complaining that a collection should be empty but isn't, you might want to see what's in there

Raymond Chen

Raymond

A programmer on the GHI team
(yes,

the same GHI team
)
reported that they were hitting an assertion failure
using an internal library and asked for help debugging it.

// All factories should be unregistered by now
assert(m_pFactoryList->IsEmpty());

“Can somebody help me figure out which factory it is that
did not get unregistered?”

I didn’t work on this internal library, but on the other hand
I’m not afraid to look inside.

Let’s see what a m_pFactory­List looks like.

0:000> ?? this->m_pFactoryList
class LookupTable<CFactory*>
   +0x000 m_uListSize      : 1 // this probably means that the list has one element
   +0x004 m_pList          : 0x00212e60 LookupTable<CFactory*>::ENTRY // this is probably the list
   +0x008 m_uCapacity      : 0x7f
0:000> ?? this->m_pFactoryList->m_pList
struct LookupTable<CFactory*>::ENTRY * 0x00212e60
   +0x000 pszName          : 0x02cf4048  "GHI_factory"
   +0x004 data             : 0x02cf4ce0 CFactory* // I bet this is the item that got leaked
0:000> dps 0x02cf4ce0 l1
02cf4ce0  6b626d58 GHI!CGhiFactory::`vftable`

No psychic powers needed here.
I just followed my nose.

The assertion says that a list is not empty.
Therefore, we should look to see what is on the list.

As a general rule, code is not intentionally written to be
impossible to understand.
The person who wrote it meant well,
so if you see a member called
m_uList­Size, it’s a pretty safe bet that it
represents the list size.
And if you see a member called
m_pList,
it probably points to the start of the list.

0 comments

Comments are closed.