Figure 1   dbgheap.c Fragment

/*
 * The following values are non-zero, constant, odd, large, and atypical
 *      Non-zero values help find bugs assuming zero filled data.
 *      Constant values are good so that memory filling is deterministic
 *          (to help make bugs reproducible).  Of course it is bad if
 *          the constant filling of weird values masks a bug.
 *      Mathematically odd numbers are good for finding bugs assuming a cleared
 *          lower bit, as well as useful for trapping on the Mac.
 *      Large numbers (byte values at least) are less typical, and are good
 *          at finding bad addresses.
 *      Atypical values (i.e. not too often) are good since they typically
 *          cause early detection in code.
 *      For the case of no-man's land and free blocks, if you store to any
 *          of these locations, the memory integrity checker will detect it.
 */

static unsigned char _bNoMansLandFill = 0xFD;   /* fill no-man's land w/this */
static unsigned char _bDeadLandFill   = 0xDD;   /* fill free objects w/this */
static unsigned char _bCleanLandFill  = 0xCD;   /* fill new objects w/this */


Figure 2   AfxAssertValidObject

void AFXAPI AfxAssertValidObject(const CObject* pOb,
    LPCSTR lpszFileName, int nLine)
{
    if (pOb == NULL) {
        TRACE0("ASSERT_VALID fails with NULL pointer.\n");
    •
    •
    •
    }
    if (!AfxIsValidAddress(pOb, sizeof(CObject))) {
        TRACE0("ASSERT_VALID fails with illegal pointer.\n");
    •
    •
    •
    }

    // check to make sure the VTable pointer is valid
    ASSERT(sizeof(CObject) == sizeof(void*));
    if (!AfxIsValidAddress(*(void**)pOb, sizeof(void*), FALSE)) {
        TRACE0("ASSERT_VALID fails with illegal vtable pointer.\n");
    •
    •
    •
    }

    if (!AfxIsValidAddress(pOb, 
        pOb->GetRuntimeClass()->m_nObjectSize, FALSE)) {
        TRACE0("ASSERT_VALID fails with illegal pointer.\n");
    •
    •
    •
    }
    pOb->AssertValid();
}