FIX: Freeing memory multiple times may cause an application error in Visual C++ (194550)

RESOLUTION

Avoid calling multiple free or multiple delete on the same pointer. One way to prevent this is by assigning the pointer to null after calling free or delete. The delete and free functions return without doing anything if a null pointer is passed as the argument. This doesn't work in cases where free or delete is called on multiple pointers pointing to the same memory location.

To help customers experiencing this problem in their third-party applications, Microsoft has released a new C-Run-time Library DLL, Msvcrt.dll, which implements two heap managers, the Visual C++ 5 compatible heap manager and the Visual C++ 6 compatible heap manager. It detects with which Visual C++ version your application is built and uses the appropriate heap manager for that application. If this version is 6.0 or greater, the Visual C++ 6 compatible heap manager is used and if it is earlier than version 6.0,the Visual C++ 5 compatible heap is used.

Visual Studio 6.0 users can get this new msvcrt.dll by installing the latest Microsoft Visual Studio Service Pack. Non-Visual Studio users should install the Microsoft Libraries Update.

STATUS

Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
This bug was corrected in Visual Studio 6.0 Service Pack 3. For more information about Visual Studio service packs, please see the following articles in the Microsoft Knowledge Base:

194022 Visual Studio 6.0 service packs, what, where, why

194295 How to tell that a Visual Studio service pack is installed

MORE INFORMATION

Freeing memory multiple times produces undefined behavior.

Release builds of the sample code below cause an application error when built with Visual C++ 6.0; the code does not cause an application error when built with Visual C++ 5.0.

Debug builds with either Visual C++ 6.0 or Visual C++ 5.0 issue an ASSERT:

   Debug Assertion Failed!

It is important to note that the state of the Small Block Heap (SBH) is constantly in flux. Because of this, there are situations where it's possible that no assertion will be issued in the debug build, but an application error will occur in the release build.

Release builds in Visual C++ 6.0 are more sensitive to freeing memory multiple times than in Visual C++ 5.0. If built with Visual C++ 5.0, the case below is one where the incorrect call to free is innocuous. If the call to free() were made more distant from the original, it is possible to cause an application error. There is a high probability that memory will be corrupted.

Sample code

   // Compile options for Release builds /c
   // Compile options for Debug builds /c /Zi
   #include <malloc.h>
   int main(int argc, char* argv[])
   {
      char *pChar1 = (char *)malloc(10*sizeof(char));
      char *pChar2 = (char *)malloc(10*sizeof(char));
      free(pChar1);
      free(pChar1);
      return 0;
   }