Posts tagged: memory leak

Memory leak in CPngImage

By , June 1, 2020 9:37 am

A memory leak in a surprising place

We’ve recently been doing some work switching our resources in our programs from BMP (using CBitmap) to PNG (using CPngImage).

At some point we got around to dog-fooding, which we do with our tools all the time, and we were surprised to see memory leaks (in the form of HGLOBAL handles) in our tools being reported by C++ Memory Validator.


We took a look and found they were coming from CPngImage::LoadFromBuffer(). Here’s the code, with the leaking lines highlighted.

BOOL svlPngImage::LoadFromBuffer(LPBYTE lpBuffer, UINT uiSize)
{
        ASSERT(lpBuffer != NULL);

        HGLOBAL hRes = ::GlobalAlloc(GMEM_MOVEABLE, uiSize); // this line leaks
        if (hRes == NULL)
        {
                return FALSE;
        }

        IStream* pStream = NULL;
        LPVOID lpResBuffer = ::GlobalLock(hRes);             // this line leaks
        ASSERT (lpResBuffer != NULL);

        memcpy(lpResBuffer, lpBuffer, uiSize);

        HRESULT hResult = ::CreateStreamOnHGlobal(hRes, FALSE, &pStream);

        if (hResult != S_OK)
        {
                return FALSE;
        }

        if (CMFCToolBarImages::m_bMultiThreaded)
        {
                CMFCToolBarImages::m_CriticalSection.Lock();
        }

        if (m_pImage == NULL)
        {
                m_pImage = new CImage;
                ENSURE(m_pImage != NULL);
        }

        m_pImage->Load(pStream);
        pStream->Release();

        BOOL bRes = Attach(m_pImage->Detach());

        if (CMFCToolBarImages::m_bMultiThreaded)
        {
                CMFCToolBarImages::m_CriticalSection.Unlock();
        }

        return bRes;
}

Verifying the memory leak

At first we thought C++ Memory Validator might have made a mistake, as it seemed unlikely that such a well used class would contain a mistake like a memory leak.

To check if this was correct memory leak report or a FALSE positive we created a test program where we can repeatedly create and destroy images in rapid succession. If the leak is real the toy program will soon fail to allocate memory. If the leak is a false positive by C++ Memory Validator, the toy program will run forever with no problems. The toy program demonstrated the leak is real – after just over 65,000 loads of an image with CPngImage, all GlobalAlloc() allocations fail.

The test program allows you to repeatedly load a BMP, a PNG into CPngImage and a PNG into an svlPngImage. The image is destroyed after loading. You can specify how many times to perform the load, 1, 10, 100, 1000, 10000, 64K and 100,000 times.


We have verified that his memory leak is present in all versions of CPngImage that ship with all versions of Visual Studio (up to and including VS2019, we haven’t looked at VS2021 yet).

Fixing the memory leak

The fix is to add two lines just before the return bRes; statement.

        ::GlobalUnlock(hRes);
        ::GlobalFree(hRes);

Unfortunately CPngImage loads it data from methods that are not virtual, so we couldn’t replace them in the implementation. We created a drop in replacement for CPngImage called svlPngImage. It’s identical to the CPngImage class with the exception that the CMFCToolBarImages calls are commented out, and the two additional lines to prevent the memory leak are added. If you’d like to use svlPngImage the source code for this drop in replacement is in the download.

Test Program Source Code

You can download the test program source code and project files.

Detecting memory leaks in ISAPI extensions

By , April 21, 2020 11:51 am

Three weeks ago I wrote about how to setup IIS for use with ISAPI extensions.

Today I’m going to show you how easy it is to monitor memory and handle allocations in IIS, and use that information to detect any memory and handle leaks that may be present in your ISAPI extension.

IIS is a very secure Windows service. The account security for IIS mean that it can’t access most parts of the Windows filesystem or even Windows objects. CGI and ISAPI extensions will only execute if you’ve configured IIS properly (see the above linked article for details). You can’t launch IIS from a tool like Memory Validator, and you can’t inject into IIS from a tool like Memory Validator because of the security constraints. That leaves you the option of using an API to interact with IIS from your tool of choice.

But I don’t want to use an API!

“But I don’t want to use an API” I hear you say. You’re concerned about having to build multiple versions of your ISAPI. One for use with Memory Validator and one for production. That’s a valid concern, but it’s not the case. You can just build one version of your ISAPI that uses Memory Validator and use that. If you haven’t done “Monitor ISAPI…” from the Launch menu prior to loading your ISAPI the Memory Validator dlls won’t be loaded. There is no dependency on Software Verify DLLs, you can ship your DLL without any need to ship the Memory Validator DLLs.

But should you need to examine memory allocation behaviour you can just fire up Memory Validator and get to work without making a special build.

ISAPI API

ISAPI extensions provide 3 APIs for IIS to use:

BOOL WINAPI GetExtensionVersion(HSE_VERSION_INFO *pVer);

BOOL WINAPI TerminateExtension(DWORD	dwFlags);

DWORD WINAPI HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB);

GetExtensionVersion() is called when the ISAPI is first loaded. We’ll use this to load Memory Validator into IIS.

TerminateExtension() is called when the ISAPI is unloaded. We’ll use this to tell Memory Validator that the work with IIS is done.

HttpExtensionProc() is used to process any requests made to the ISAPI extension.

Memory Validator API

To add the Memory Validator API to the ISAPI we do the following to the ISAPI source code:


  1. Add two header files:

    #include "svlMVStubService.h"
    #include "svlServiceError.h"
    

  2. We add the following code to GetExtensionVersion(). This includes logging success and failure so that we can identify if anything has gone wrong. Without the logging determining failure inside of IIS is very hard (a debugger and a special build of the Memory Validator DLL is required).

        // load Validator here
    
        svlMVStub_setLogFileName(L"C:\\testISAPIWebsite\\svl_MV_log.txt");
        svlMVStub_deleteLogFile();
    
        SVL_SERVICE_ERROR   errCode;
    #ifdef IS6432
        // x86 with x64 GUI
        errCode = svlMVStub_LoadMemoryValidator6432();
    #else   //#ifdef IS6432
        // x86 with x86 GUI
        // x64 with x64 GUI
        errCode = svlMVStub_LoadMemoryValidator();
    #endif   //#ifdef IS6432
        if (errCode != SVL_OK)
        {
            DWORD   lastError;
    
            lastError = GetLastError();
            svlMVStub_writeToLogFileW(L"C++ Memory Validator load failed. \r\n");
            svlMVStub_writeToLogFileLastError(lastError);
            svlMVStub_writeToLogFile(errCode);
    
            svlMVStub_dumpPathToLogFile();
        }
        else
        {
            svlMVStub_writeToLogFileW(L"C++ Memory Validator load success. \r\n");
    
            errCode = svlMVStub_StartMemoryValidatorForIIS();
    	if (errCode != SVL_OK)
    	{
                DWORD   lastError;
    
                lastError = GetLastError();
                svlMVStub_writeToLogFileW(L"Starting C++ Memory Validator failed. \r\n");
                svlMVStub_writeToLogFileLastError(lastError);
                svlMVStub_writeToLogFile(errCode);
    	}
    
            svlMVStub_writeToLogFileW(L"Finished starting C++ Memory Validator\r\n");
        }
    

    You’ll need to edit the location of the logfile to match the name of your website directory.

  3. We add the following code to TerminateExtension().

        // unload Validator here
    
        svlMVStub_UnloadMemoryValidator();
    


Monitoring memory allocations

Start Memory Validator.

From the Launch menu choose the IIS sub menu and then Monitor ISAPI….

The monitor ISAPI dialog is displayed. Any settings from a previous launch are displayed. Edit the settings appropriately.

You need to identify the ISAPI dll that is being processed, the website directory, the IIS process (choose Any IIS if you don’t know or don’t care), the web browser (the default is Microsoft Edge as it seems more tolerant of data format errors than Chrome) and finally the URL you wish to use to test the ISAPI.

Click OK.

Memory Validator copies some DLLs to the directory containing the ISAPI, sets up various variables that will be used inside the IIS process, resets IIS, and launches the web browser to load the specified URL that will load the ISAPI.

When you’ve finished interacting with the ISAPI, you’ll need to stop IIS. Go to the Launch menu, choose the IIS sub menu then Stop IIS.

When IIS has stopped executing Memory Validator displays “Ready” on the status bar, the Memory tab will show any memory leaks and handle leaks that are present.

A short video of this process is shown below.

Conclusion

We’ve completely reworked our ISAPI support so that you have very little to do, just use the API as shown above and launch using the Monitor ISAPI command.

In comparison, here are some instructions for using Boundschecker with IIS. These are out of date and will no longer work. But look how much you have to do manually.

Detecting memory leaks in Visual Test unit tests

By , June 6, 2018 5:40 pm

Introduction

We recently had a request asking if C++ Memory Validator could detect memory leaks in unit tests managed by Microsoft’s Visual Test and Visual Test Explorer. They told us what they’d tried to do and that it had failed. Our response was to find out what was failing, fix it and then describe what you need to do to use our tools with Visual Test. That’s what this article is about.

There were a few bugs specific to working with Visual Test, plus a very novel environment variable data corruption that can only happen in very unusual circumstances (you almost certainly would not hit these in normal usage of our tools). We fixed these tools, then experimented with several ways of working with Visual Test. We’re only going to talk about C++ Memory Validator here, but this article also applies to our Coverage, Performance and Thread tools.

You can run Visual Test from the command line, and also via Visual Test Explorer, which is a component of Visual Studio.

Monitoring Visual Test from the command line

The full details of how to work with Visual Test from the command line are documented in this article from Microsoft.

Using this information we know that we need to launch vstest.console.exe and pass the unit test DLL to that as an argument. For example:

vstest.console.exe unitTest.dll 

Using this information we can launch vstest.console.exe from C++ Memory Validator and pass it the appropriate DLL. You can set the startup directory to whatever you like. We’ve chose to set it to the same directory as the unit test DLL.

Unit Test Code

namespace UnitTest1
{		
	TEST_CLASS(UnitTest1)
	{
	public:
		
		TEST_METHOD(TestMethod1)
		{
			// pretend this is a real unit test, 
			// exercising a real target class/function
			// and that it leaks some memory

			char *ptr;

			ptr = new char[123];
			strcpy_s(ptr, 123, "Excellent Adventure");

			ptr = (char *)malloc(456);
			strcpy_s(ptr, 456, "Bogus Journey");

			ptr = (char *)malloc(789);
			strcpy_s(ptr, 789, "Face the Music");

			Assert::AreNotEqual("Bill", "Ted");
		}

	};
}

You’ll notice that you don’t need to specify the TEST_MODULE_INITIALIZE(moduleInit) function, or the TEST_MODULE_CLEANUP(moduleCleanup) function. You only need to specify the unit tests you want tested. C++ Memory Validator does the rest.

Monitoring Visual Test Explorer

When working with Visual Test Explorer, Visual Test is launched from Dev Studio, and then loads the unit tests for testing from a DLL. Visual Test then stays running in the background and does not shutdown. This means the “program has ended” signal that C++ Memory Validator needs doesn’t get sent. It also means that subsequent tests run with Visual Test Explorer won’t cause Visual Test to startup, meaning that the “program has started” signal that C++ Memory Validator needs doesn’t get sent.

To get around these problems we need to use the NT Service API (see help file, or online documentation for details) to contact C++ Memory Validator at the start of the unit tests, and also at the end of the unit tests. We do that using the TEST_MODULE_INITIALIZE(moduleInit) function, or the TEST_MODULE_CLEANUP(moduleCleanup) functions.

Functions

We use svlMVStub_LoadMemoryValidator() to load C++ Memory Validator into the unit test, then svlMVStub_StartMemoryValidator() to start it monitoring the unit test and communicating with the user interface. At the end of the tests we use svlMVStub_UnloadMemoryValidatorAndTerminateProcess(1000) to shutdown C++ Memory Validator and set a thread running that will after a delay of 1000ms terminate the vstest.executionengine.x86.exe (Visual Test) process. You may need to experiment with this delay on your machine.

Header Files

We need to include two header files from C++ Memory Validator. svlMVStubService.h and svlServiceError.h. You’ll find these in the svlMVStubService folder in the C++ Memory Validator install directory.

Libraries

We also need to link to svlMVStubService.lib (32 bit builds) or svlMVStubService_x64.lib (64 bit builds). You’ll find versions of these libraries in the svlMVStubService folder (one library per version of Visual Studio).

Unit Test Code

#include "svlMVStubService.h"
#include "svlServiceError.h"

namespace UnitTest1
{		
	TEST_MODULE_INITIALIZE(moduleInit)
	{
		SVL_SERVICE_ERROR	sse;

		sse = svlMVStub_LoadMemoryValidator();

		sse = svlMVStub_StartMemoryValidator();
	}

	TEST_MODULE_CLEANUP(moduleCleanup)
	{
		SVL_SERVICE_ERROR	sse;
		
		sse = svlMVStub_UnloadMemoryValidatorAndTerminateProcess(1000);
	}

	TEST_CLASS(UnitTest1)
	{
	public:
		
		TEST_METHOD(TestMethod1)
		{
			// pretend this is a real unit test, 
			// exercising a real target class/function
			// and that it leaks some memory

			char *ptr;

			ptr = new char[123];
			strcpy_s(ptr, 123, "Excellent Adventure");

			ptr = (char *)malloc(456);
			strcpy_s(ptr, 456, "Bogus Journey");

			ptr = (char *)malloc(789);
			strcpy_s(ptr, 789, "Face the Music");

			Assert::AreNotEqual("Bill", "Ted");
		}

	};
}

Having reworked the unit tests to support the NT Service API, we now need to launch devenv.exe from C++ Memory Validator, but with instructions to ignore devenv.exe and monitor Visual Test (vstest.executionengine.x86.exe). We do that from the launch dialog/wizard.

First choose devenv.exe to monitor using the Browse… button next to the Application to launch field. In this example we chose C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe


Next we need to setup the applications to monitor. Click the Edit… button next to the Application to monitor field. The applications to monitor dialog is displayed.


Choose devenv.exe using the Browse… button next to the Application to launch field.

Click the Add… button and add the vstest.executionenginex86.exe that corresponds with the devenv.exe you selected. In this example we chose C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstestexecutionengine.x86.exe. Be sure to choose the correct one – there are several with similar names to choose from.


Click OK to accept the application to monitor.


Click OK to accept the new definitions.

Now on the launch dialog, change the Application to monitor combo to select the vstest.execution.x86.exe entry.

Enter the name of your unit test dll(s) in the Arguments field, separated by spaces. If you specify the directory containing the DLLs as the startup directory, you can specify the DLL names without paths.

Running Your Tests

Now that we’ve setup C++ Memory Validator to monitor Visual Test when started from devenv, let’s get to work.

To start devenv, click the Go! button. Devenv will start. Load the solution that contains your unit tests. When you choose Run Selected Tests or Debug Selected Tests from Visual Test Explorer, the tests will run and will be monitored by C++ Memory Validator at the same time.

The nine types of memory leak

By , September 30, 2011 1:48 pm

Memory leaks affect all computer programs be they desktop applications, service applications or web services. For many trivial applications or applications with a very short application lifetime the odd memory leak is often not of significant importance and will go un-noticed. However for larger applications that use lots of memory or which need to run for a long time (for example web-servers) memory leaks are a serious problem.

Handle Leaks

This article is specifically talking about memory leaks. However handle leaks are just as serious. Not every item in this article has a corresponding handle leak equivalent. However some of the memory leaks shown do have corresponding handle leak equivalents. So if you are concerned about handle leaks, please read this article and just think about handles rather than memory. Most of the examples will apply.

The consequences of memory leaks?

  • Left unchecked memory leaks with ultimately result in the failure of the application to function when requests to allocate memory fail.
  • Memory leaks often mask other problems such as memory corruptions, buffer overruns and buffer underruns. When the leak is fixed these other problems often reveal themselves showing you that the application has more serious problems that also need to be addressed.

Why should you fix memory leaks?

  • Fixing memory leaks often reveals buffer overruns, buffer underruns, memory corruptions, calling functions on deleted objects (which will lead to indeterminate behaviour), multiple access to memory that was freed (incorrect memory access problems). Fixing these problems then results in an overall boost in application software quality, reliability and robustness.
  • Fixing memory leaks improves your application’s memory footprint allowing it to run for longer without errors and failures of operation. This in turn leads to greater user/customer satisfaction.

One proposed solution to memory leaks is to use garbage collection. Garbage collection removes the responsibility of deallocating memory from the programmer. Well, that is the theory. The reality is that garbage collected languages and technologies (.Net, C#, Java, Python, Ruby, etc) can all suffer from memory leaks caused by the programmer forgetting to set references to objects to NULL when they have finished with them. Garbage collection simply changes the cause of the memory leak from forgetting to deallocate the memory to forgetting to reset the reference to NULL. Either way the memory gets leaked. However the fix for deterministic memory leaks is often much easier to determine whereas for garbage collected memory leaks identifying where reset object references is not always so easy.

In this article we are concerned with deterministic memory leaks – the type of memory leak you may get when using a language such as C, C++, Delphi, Fortran, etc – non garbage collected allocations.

We will cover garbage collected memory leaks in another article.

How to deallocate memory.

You should always use the correct deallocator to deallocate memory allocated by an allocator. Array allocations should be matched with array deallocations and single object allocations should be matched with single object deallocations.

malloc free
calloc free
realloc free
_expand free
new delete
new [] delete []
HeapAlloc HeapFree
HeapReAlloc HeapFree
LocaAlloc LocalFree
GlobalAlloc GlobalFree
VirtualAlloc VirtualFree
SysAllocString SysFreeString
CoTaskMemAlloc CoTaskMemFree
CoTaskMemRealloc CoTaskMemFree

Memory leaks fall into one of several categories.

We have identified nine broad categories of memory leak. Some of them are variations of other memory leaks, often with different program scope. We are going outline them all here so that you are aware of them. We will also identify example solutions for each type of memory leak.

#1 Leaked temporary workspace.

This is memory that is allocated inside a function or class method and which is not deallocated before the function completes.

HANDLE createCommsHandle(DWORD	id)
{
	char	*name;
	HANDLE	handle = NULL;

	name = new char [100];
	if (name != NULL)
	{
		sprintf(name, "workstation%d", id);
		handle = createHandle(name);
	}

	return handle;
}

In the above function the memory allocated for the name variable is not deallocated after the call to createHandle().

Solution:

HANDLE createCommsHandle(DWORD	id)
{
	char	*name;
	HANDLE	handle = NULL;

	name = new char [100];
	if (name != NULL)
	{
		sprintf(name, "workstation%d", id);
		handle = createHandle(name);

		delete [] name;
	}

	return handle;
}

#2 Leaked data member

This is memory allocated for use by a class member, but which is not deallocated before the class object is destroyed.

class commsHandle
{
public:
	commsHandle();

	~commsHandle();

	void setName(char	*p_name);

	void createCommsHandle();

private:
	HANDLE	handle;
	char	*name;
};

commsHandle::commsHandle()
{
	name = NULL;
	handle = NULL;
}

commsHandle::~commsHandle()
{
	if (handle != NULL)
		CloseHandle(handle);
}

void commsHandle::setName(char	*p_name)
{
	size_t	len;

	len = strlen(p_name);
	name = new char [len + 1];
	if (name != NULL)
	{
		strcpy(name, p_name);
	}
}

void commsHandle::createCommsHandle()
{
	HANDLE	handle = NULL;

	handle = createHandle(name);

	return handle;
}

The above class has two problems:
#1 the destructor does not deallocate the memory allocated in setName().
#2 setName() does not deallocate the memory allocated in setName() prior to allocating a new value for name.

Solution:

commsHandle::~commsHandle()
{
	if (handle != NULL)
		CloseHandle(handle);

	if (name != NULL)
		delete [] name;

}

void commsHandle::setName(char	*p_name)
{
	if (name != NULL)
	{
		delete [] name;
		name = NULL;
	}

	size_t	len;

	len = strlen(p_name);
	name = new char [len + 1];
	if (name != NULL)
	{
		strcpy(name, p_name);
	}
}

#3 Leaked class static data member

This memory is allocated for use only by many functions of a class, but shared across all instances of that class.

class commsHandle
{
public:
	commsHandle();

	~commsHandle();

	static void setName(char	*p_name);

	void createCommsHandle();

private:
	HANDLE		handle;
	static char	*name;
};

commsHandle::commsHandle()
{
	handle = NULL;
}

commsHandle::~commsHandle()
{
	if (handle != NULL)
		CloseHandle(handle);
}

void commsHandle::setName(char	*p_name)
{
	size_t	len;

	len = strlen(p_name);
	name = new char [len + 1];
	if (name != NULL)
	{
		strcpy(name, p_name);
	}
}

void commsHandle::createCommsHandle()
{
	HANDLE	handle = NULL;

	handle = createHandle(name);

	return handle;
}

The above class has two problems:
#1 setName() does not deallocate the memory allocated in setName() prior to allocating a new value for name.
#2 there is no function to deallocate the memory allocated in setName() – it is not possible to call a function to cleanup this memory allocation.

Solution:

class commsHandle
{
public:
	commsHandle();

	~commsHandle();

	static void flushName();

	static void setName(char	*p_name);

	void createCommsHandle();

private:
	HANDLE		handle;
	static char	*name;
};

void commsHandle::flushName()
{
	if (name != NULL)
	{
		delete [] name;
		name = NULL;
	}
}

void commsHandle::setName(char	*p_name)
{
	flushName();

	size_t	len;

	len = strlen(p_name);
	name = new char [len + 1];
	if (name != NULL)
	{
		strcpy(name, p_name);
	}
}

With the above solution commsHandle::flushName() needs to be called during program shutdown (or at the end of main()).

#4 Leaked global memory

This memory is allocated for use by many functions and is not part of a class.

char *name;

void setName(char	*p_name)
{
	size_t	len;

	len = strlen(p_name);
	name = new char [len + 1];
	if (name != NULL)
	{
		strcpy(name, p_name);
	}
}

Solution:

char *name;


void flushName()
{
	if (name != NULL)
	{
		delete [] name;
		name = NULL;
	}
}


void setName(char	*p_name)
{

	flushName();

	size_t	len;

	len = strlen(p_name);
	name = new char [len + 1];
	if (name != NULL)
	{
		strcpy(name, p_name);
	}
}

With the above solution flushName() needs to be called during program shutdown (or at the end of main()).

#5 Leaked static memory

This memory is allocated soley for use by the function in which is is declared.

void doWork()
{
	static	char	*workspace = NULL;

	if (workspace == NULL)
	{
		workspace = new char [1000];
	}

	...
}

This is a similar leak to #4 except the scope of the memory is restricted to the function (or enclosing scope if declared at a deeper nesting level). The main problem with this allocation style is that there is no easy way to deallocate the memory if the memory is intended to be allocated only on the first call to the function (detected by the if (workspace == NULL) comparison).

Solution:

The solution is to provide an allocation function and a deallocation function. The allocation function getWorkSpace() is called from doWork() and the deallocation function flushWorkSpace() is called during program shutdown or at the end of main().


char *getWorkSpace(); // forward reference

void doWork()
{

	char	*workspace;

	workspace = getWorkSpace();


	...
}


static char *theWorkspace = NULL;

char *getWorkSpace()
{
	if (workSpace == NULL)
		theWorkSpace = new char [1000];

	return theWorkSpace;
}

void flushWorkSpace()
{
	delete [] theWorkSpace;
	theWorkSpace = NULL;
}


int main(int argc, char *argv[])
{
	...
	
	// end of program

	flushWorkSpace();

}

#6 Leaked worker object

This is when memory is allocated by function X and then passed to function Y to do a job and function X does not cleanup because it expects function Y to cleanup. A common case of this is when a function on one thread creates a data object to pass to a function on another thread.

// code on Thread 1

void processData(DWORD	id,
		 DWORD	tag,
		 DWORD	value)
{
	workerData	*wd;

	wd = new workerData(id, tag, value);
	if (wd != NULL)
	{
		addWorkerToQueue(wd);
	}	
}

void addWorkerToQueue(workerData	*wd)
{
	CCriticalSection	lock(§, TRUE);

	dataItems.Add(wd);
}

// code on Thread 2

void processQueue()
{
	CCriticalSection	lock(§, TRUE);
	DWORD			i, n;

	n = dataItems.GetSize();
	for(i = 0; i < n; i++)
	{
		workerData	*wd;

		wd = dataItems.GetAt(i);
		if (wd != NULL)
		{
			wd->doWork();
		}
	}

	dataItems.RemoveAll();
}

Solution:

The solution is to delete the worker objects once they have been use to do their work.

void processQueue()
{
	CCriticalSection	lock(§, TRUE);
	DWORD			i, n;

	n = dataItems.GetSize();
	for(i = 0; i < n; i++)
	{
		workerData	*wd;

		wd = dataItems.GetAt(i);
		if (wd != NULL)
		{
			wd->doWork();

			delete wd;

		}
	}

	dataItems.RemoveAll();
}

#7 Incorrect array delete memory leak

With C++ you can allocate arrays of objects and deallocate arrays of objects. The array form of delete is specified using [] and the non-array form of delete is specified without using [].

class memObj
{
public:
	memObj();

	~memObj();

	... // other functions

private:
	char	*data;
};

memObj::memObj()
{
	data = new [1000];
}

memObj::~memObj()
{
	delete [] data;
}

Consider this object definition that allocates memory in its constructor and deallocates memory in its destructor. On the face of it this does not look like it could leak memory. Well, it can if you allocate it in arrays and deallocate the array incorrectly…

	memObj	*array;

	array = new [10] memObj();

	delete array;

The above code allocates an array of 10 memObj objects then deallocates the array. The space for the array is deallocated but the destructor for each of the 10 memObj objects is only called for the first object. The other nine do not have their destructors called which means that each of the nine memObj objects leaks the memory it holds.

Solution:

	memObj	*array;

	array = new [10] memObj();

	delete [] array;

For instrinsic datatypes and simple objects that have no virtual functions and contain only intrinsic datatypes there may be no real damage by deallocating an array of objects using delete. But that leaves the door open to a memory leak should someone modify the object definition to be more complex or to have virtual functions. Thus you should always deallocate arrays using delete [] (even for intrinsics in case someone modifies the datatype of the intrinsic from say "int" to "complexNumber").

#8 Virtual object memory leak

Virtual functions are used in C++ to provide implementations of a function for an object that is derived from another object. For example an apple object would implement a different flavour() function than a pear object, both objects would be derived from a base class fruit. Objects that are derived from other objects must always have a virtual destructor in the base class. If the base class is not declared as virtual the destructors for the derived objects will not be called, resulting in memory leaks if those objects are meant to deallocate memory.

First we need to define a base class and some derived classes.

class train
{
public:
	train()

	~train();
};

train::train()
{
	...
}

train::~train()
{
	...
}

class steamTrain : public train
{
public:
	steamTrain();

	~steamTrain();

	void addFuel(int quantity);

private:
	coal	*fuel;
	DWORD	amount;
};

steamTrain::steamTrain()
{
	amount = 100;
	fuel = NULL;
	addFuel(amount);
}

steamTrain::~steamTrain()
{
	delete [] fuel;
}

void steamTrain::addFuel(int quantity)
{
	amount += quantity;
	delete [] fuel;
	fuel = new [amount] coal;
}

class electricTrain : public train
{
public:
	electricTrain();

	~electricTrain();

	void powerOn();

	void powerOff();

private:
	pantograph *power;
};

electricTrain::electricTrain()
{
	power = NULL;
}

electricTrain::~electricTrain()
{
	delete power;
}

void electricTrain::powerOn()
{
	delete power;
	power = new pantograph();
}

void electricTrain::powerOff()
{
	delete power;
	power = NULL;
}

Now if we use these object definitions…

	train	*steam = new steamTrain();
	train	*electric = new electricTrain();

	...

	delete steam;
	delete electric;

When the above code is executed the destructor for class train is called for both objects electric and steam. But the destructors for class steamTrain and class electricTrain is not called. This results in a memory leak of the coal and pantograph objects. The reason the destructors are not called is because the destructor for class train was not declared virtual.

Solution:

class train
{
public:
	train()

	virtual ~train();

};

#9 Calling the wrong deallocator

A form of memory leak we’ve seen a few times is caused by the wrong deallocator being used for a given allocator.

char *ptr;

ptr = new char [100];
free(ptr);

HLOCAL loc;

loc = LocalAlloc(LMEM_FIXED, 1000:
GlobalFree(loc);

When you do this different things can happen depending upon what the allocating function was and what the deallocating function is. Possible outcomes are:

  • Memory gets deallocated successfully! This can happen – if the implementation of delete calls free() then some calls to delete will succeed if the memory was allocated by malloc(). We do not recommend doing this. This relies upon implementation dependent details that may change with a future version of the compiler, or change between debug and release builds. This is also a serious impediment to writing portable code should you be writing for more than one operating system.
  • Memory does not get deallocated. Program execution continues as normal and no damage is done to the program.
  • Memory does not get deallocated. Program execution continues as normal but damage is done to heap datastructures in the program. This damage may lead to "random" crashes in your application some time later.
  • Memory does not get deallocated. Program crashes. When this happens you have a strong indicator something is wrong and you may well identify the calling of the wrong deallocator as the cause of the crash.

You should always deallocate using the documented deallocator and if applicable the correct form of array/single declaration (for new/delete and new []/delete []).

Additional types of memory leak

Some programming styles allocate memory once early in the program lifetime and deliberately never deallocate the memory.

static char *longLife = NULL;

// getLongLife called from other parts of the program

char *getLongLife()
{
	return longLife();
}

int main(int  argc,
	 char *argv[])
{
	longLife = new char [1000];

	doWork();
}

This is a one-shot memory allocation intended to last the entire program lifetime because the program authors think the memory may be useful at any stage in the application, including deep inside the program shutdown sequence.

This may happen for some multi-threaded applications where the memory is shared between many threads and for whatever reason the program authors do not think it wise to clean the memory up. One example of this was the lazy allocation of thread local data in earlier versions of Microsoft’s C runtime. The CRT made no attempt to cleanup the memory when the program exited. More recent versions of Microsoft’s CRT have a different behaviour.

Other reasons can be creating workspace for debugging tools injected into a program where the tool expects to try to report data as far into program shutdown as it can go. As such the tool will want its workspace available until the operating system pulls the rug out from under it (which in our experience, is pretty much what happens, if you can fool the OS into letting your DLL last past its DllMain when it would normally be closed you won’t get a second notification that your DLL is going to be killed).

In our experience, although it may be convenient to have a programming style where you can just allocate a whole-application-lifetime object and not-deallocate it this programming style hinders the use of memory debugging tools (by all vendors, not just ourselves) as this whole-application-lifetime object will always be reported as a leak (because it never gets deallocated). That in turn means your memory-leak fix team need to be aware of this object (these objects!) and ignore it. Depending upon your application this can be a waste of developer time.

Much better and tidier to deallocate all memory allocations in every circumstance you can make it happen.

Panorama Theme by Themocracy