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

January 31st, 20140 0

A programmer on the GHI team(yes,the same GHI team)reported that they were hitting an assertion failureusing 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 thatdid not get unregistered?”

I didn’t work on this internal library, but on the other handI’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 beimpossible to understand.The person who wrote it meant well,so if you see a member calledm_uList­Size, it’s a pretty safe bet that itrepresents the list size.And if you see a member calledm_pList,it probably points to the start of the list.

Raymond Chen