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

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

"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.

Comments (11)
  1. Joshua says:

    I have this nasty habit of keeping a usize right next to an asize. If you don't know the idiom you get stuck. Then again, if you leak I don't check. It comes down to at that point "Why the heck did you call one of the methods after unloading my DLL."

  2. aaron says:

    "As a general rule, code is not intentionally written to be impossible to understand. The person who wrote it meant well."

    Oh, if only that were true…. so much of my company code has utterly indecipherable names.

    SupplyLocationViewGrouperForm (is neither a View, a Form, nor a Location. And it only has a member that is a "Group".  It is not a Group itself. I think "Groupers" are things that have groups in them, but I'm not sure. There is more bad code out there than most people can imagine.

    [But was it written to be intentionally obtuse? Or did the original author mean well but not have a clue? -Raymond]
  3. mikeb says:


    >> If you don't know the idiom

    I don't know the idiom. In case I ever come across it, what would `usize` and `asize` mean?

  4. Gabe says:

    mikeb: I don't know the idiom either, but I would guess that "usize" means "used size" and "asize" means "allocated size". I would also expect that the used size would be no more than the allocated size.

  5. Joshua says:

    Gabe guesses well. It's the array growth idiom for amortizing resizes.

  6. But he shouldn't have to guess. That's the aforementioned well meaning :)

  7. Azarien says:

    "code is not intentionally written to be impossible to understand" unless you're dealing with DRM, activation or similarly evil things.

    [That's specifically why I added the weasel words "as a general rule", thanks for ignoring them. -Raymond]
  8. Neil says:

    If only there was some way of querying the allocated size from the allocator…

  9. Joker_vD says:

    @Joshua: Why not "used_size" and "alloc_size"? I believe modern compilers support identifiers longer than 6 symbols.

  10. Joshua says:

    @Joker_vd: When you've done most of your programming without autocomplete you develop habits that involve short symbol names. The resulting idioms don't change without active effort even though names may now be plenty long.

  11. Joker_vD says:

    @Joshua: Try to use properly configured emacs? Or are you stuck with nano/Notepad?

    @Azarien: AFAIK, this stuff is usually "put on top" (like, obfuscators and protectors, such as Armadillo).

Comments are closed.

Skip to main content