FIX: Assertion Failed Line 178 or Line 527 in ARCCORE.CPP

Last reviewed: September 18, 1997
Article ID: Q128113
1.00 1.50 1.51 | 1.00 2.00
WINDOWS        | WINDOWS NT
kbprg kbbuglist kbfixlist kbcode

The information in this article applies to:

  • The Microsoft Foundation Classes (MFC), included with:

        - Microsoft Visual C++ for Windows, versions 1.5 and 1.51
        - Microsoft Visual C++, 32-bit Edition, versions 1.0 and 2.0
    

SYMPTOMS

If a CArchive object is used with a user-defined buffer and the buffer is destroyed before the CArchive object has been destroyed, an assertion failure might occur. The message in the output window would be similar to:

  • Test Windows Application: File arccore.cpp, Line 178, Assertion Failed!

    -or-

  • Test Windows Application: File arccore.cpp, Line 527, Assertion Failed!

This will happen even if the CArchive object has been properly closed by using the CArchive::Close function.

CAUSE

The CArchive destructor can be found in the <MSVC install>\MFC\SRC directory in the file ARCCORE.CPP. The function is implemented as follows:

// In 16-bit MFC:

CArchive::~CArchive() {
  ASSERT(AfxIsValidAddress(m_lpBufStart,
     (UINT)(m_lpBufMax - m_lpBufStart)));
  // ...
  // ...
}

// In 32-bit MFC:

CArchive::~CArchive() {
  ASSERT(m_bDirectBuffer || m_lpBufStart != NULL);
  ASSERT(m_bDirectBuffer ||
      AfxIsValidAddress(m_lpBufStart,m_lpBufMax - m_lpBufStart,
         IsStoring()));
  // ...
  // ...
}

If a user-defined buffer is used for the archive (by passing it in as the lpBuf parameter to the CArchive constructor), it should be valid to call CArchive::Close on the archive, and then destroy the buffer before destroying the CArchive object. However, the above ASSERT will be executed when the CArchive object is destroyed whether the user-supplied buffer has been destroyed or not.

If the buffer is destroyed before the CArchive object is destroyed, m_lpBufStart might no longer point to a valid memory address. By default it points to the address of the user-supplied buffer.

RESOLUTION

  1. You can safely ignore the assertion failure. It is harmless.

  2. If you are using a user-supplied buffer, ensure that the CArchive object is destroyed before the buffer is freed. If the CArchive object is allocated on the stack, it can be allocated on the heap so that the CArchive object can be destroyed before the buffer, as in this example:

       char *pBuf = new char[516];
       CFile file("C:\\TMP.DAT",CFile::modeCreate | CFile::modeWrite);
       CArchive *pArchive = new CArchive(&file,CArchive::store,
                                          512,pBuf);
       // Use pArchive in here, then destroy it
       delete pArchive;
    
       // NOW free up the buffer
       delete pBuf;
    
    

STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. This bug was corrected in Microsoft Visual C++ for Windows, version 1.52 and in Microsoft Visual C++, 32-bit Edition, version 2.1.


Additional reference words: 1.00 1.50 1.51 2.00 2.50 2.51 2.10 3.00 3.10
globalalloc load store
KBCategory:kbprg kbbuglist kbfixlist kbcode
KBSubcategory: MfcFileIO MfcMisc
Keywords : MfcFileIO MfcMisc kbbuglist kbcode kbfixlist kbprg
Technology : kbMfc
Version : 1.00 1.50 1.51 | 1.00 2.00
Platform : NT WINDOWS
Solution Type : kbfix


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 18, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.