Ich kann nicht schlafen :)

Ich habe ein ziemlich großes Projekt unter Windows und habe einige Probleme mit der Heap-Korruption festgestellt. Ich habe alles SO gelesen, einschließlich dieses schönen Themas:Wie kann man Heap-Korruptionsfehler debuggen?Allerdings war nichts geeignet, um mir von der Stange zu helfen.Debug CRT undBoundsChecker Es wurden Heap-Beschädigungen festgestellt, aber die Adressen waren immer unterschiedlich und der Erkennungspunkt war immer weit vom tatsächlichen Überschreiben des Speichers entfernt. Ich habe erst mitten in der Nacht geschlafen und den folgenden Hack erstellt:

DWORD PageSize = 0;

inline void SetPageSize()
{
    if ( !PageSize )
    {
        SYSTEM_INFO sysInfo;
        GetSystemInfo(&sysInfo);
        PageSize = sysInfo.dwPageSize;
    }
}

void* operator new (size_t nSize)
{
    SetPageSize();
    size_t Extra = nSize % PageSize;
    nSize = nSize + ( PageSize - Extra );
    return Ptr = VirtualAlloc( 0, nSize, MEM_COMMIT, PAGE_READWRITE);
}

void operator delete (void* pPtr)
{
    MEMORY_BASIC_INFORMATION mbi;
    VirtualQuery(pPtr, &mbi, sizeof(mbi));
    // leave pages in reserved state, but free the physical memory
    VirtualFree(pPtr, 0, MEM_DECOMMIT);
    DWORD OldProtect;
    // protect the address space, so noone can access those pages
    VirtualProtect(pPtr, mbi.RegionSize, PAGE_NOACCESS, &OldProtect);
}

Einige Heap-Korruptionsfehler wurden offensichtlich und ich konnte sie beheben. Beim Beenden wurden keine Debug-CRT-Warnungen mehr ausgegeben. Ich habe jedoch einige Fragen zu diesem Hack:

1. Kann es falsch positive Ergebnisse liefern?

2. Kann es einige der Haufenverfälschungen verfehlen? (Auch wenn wir malloc / realloc / free ersetzen?)

3. Es kann nicht mit 32-Bit ausgeführt werdenOUT_OF_MEMORYNur für 64-Bit. Habe ich recht, dass uns einfach der virtuelle Adressraum für 32-Bit-Dateien ausgeht?