Memory that is freed multiple times may cause an
application error. NOTE
: This is true whether you use malloc and multiple free or new and
Heap control structures are modified after the first call
to free() and no longer in a state where subsequent calls to free() will work.
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
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
Microsoft has confirmed that this is a bug in the Microsoft
products that are listed at the beginning of this article.
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:
Visual Studio 6.0 service packs, what, where, why194295
How to tell that a Visual Studio service pack is installed
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:
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.
// Compile options for Release builds /c
// Compile options for Debug builds /c /Zi
int main(int argc, char* argv)
char *pChar1 = (char *)malloc(10*sizeof(char));
char *pChar2 = (char *)malloc(10*sizeof(char));