FIX: CMemFile Causes GP Faults in Debug with _AFXDLL |
Q104703
1.00 WINDOWS kbprg kbfixlist kbbuglist ---------------------------------------------------------------------- The information in this article applies to: - The Microsoft Foundation Classes (MFC), included with: - Microsoft Visual C++ for Windows, version 1.0 ---------------------------------------------------------------------- SYMPTOMS ======== If a CMemFile object is used in the _DEBUG version of an application or extension dynamic-link library (DLL) that links to the MFC200D.DLL, that application or DLL may generate a general protection (GP) fault. The problem occurs if enough data is added to the CMemFile object to cause it to reallocate a larger block of memory for the CMemFile. After doing this, the application's heap is corrupted and a GP fault is likely to occur soon afterward. CAUSE ===== The debug version of AfxAppReAlloc() in the MFC200D.DLL is not implemented correctly; the normal nondebug version of AfxAppReAlloc() is used, which does not allocate memory on the heap in the same way as AfxAppAlloc() and AfxAppFree(). This causes the heap to be corrupted when AfxAppReAlloc() is called. Because AfxAppReAlloc() is used to resize the memory buffer for CMemFile objects, using CMemFile objects can cause GP faults. To workaround this problem, derive a new class from CMemFile and override the GrowFile() function. Copy the original code for GrowFile() in FILEMEM.CPP, modify the call to ReAlloc(), and have it call Alloc() and free() to resize the buffer. Because these functions do work correctly in _DEBUG, this will correct the problem. The following code fragment demonstrates how to derive a class from CMemFile and implement the GrowFile() function: In the .H File -------------- class CMyMemFile : public CMemFile { public: CMyMemFile(int nGrowFile=1024) : CMemFile(nGrowFile) {} protected: void GrowFile(DWORD dwNewLen); }; And in the .CPP File -------------------- void CMyMemFile::GrowFile(DWORD dwNewLen) { ASSERT_VALID(this); ASSERT((dwNewLen & 0xFFFF0000L) == 0L); if (dwNewLen > m_nBufferSize) { // Grow the buffer. DWORD dwNewBufferSize = (DWORD)m_nBufferSize; while (dwNewBufferSize < dwNewLen) dwNewBufferSize += m_nGrowBytes; if (dwNewBufferSize > USHRT_MAX) AfxThrowFileException(CFileException::diskFull); ASSERT((dwNewBufferSize & 0xFFFF0000L) == 0L); BYTE FAR* lpNew; if (m_lpBuffer == NULL) lpNew = Alloc((UINT)dwNewBufferSize); else { #ifdef _DEBUG lpNew = Alloc( (UINT)dwNewBufferSize); _fmemcpy(lpNew,m_lpBuffer,m_nBufferSize); free(m_lpBuffer); #else lpNew = Realloc(m_lpBuffer, (UINT)dwNewBufferSize); #endif } if (lpNew == NULL) AfxThrowMemoryException(); m_lpBuffer = lpNew; m_nBufferSize = (UINT)dwNewBufferSize; } ASSERT_VALID(this); } STATUS ====== Microsoft has confirmed this to be a problem in the Microsoft Foundation Classes (MFC) version 2.0. This problem has been fixed in MFC version 2.5. Additional reference words: 1.00 2.00 GP-Fault GPF KBCategory: kbprg kbfixlist kbbuglist KBSubcategory: MfcDLL
Keywords : kb16bitonly kbDLL kbMFC kbVC
Issue type :
Technology : kbAudDeveloper kbMFC
Last Reviewed: May 5, 2001 |
