Memory leak is failure to release memory that was acquired from the heap. It could be as simple as doing a new and forgetting a corresponding delete. On the other hand you could say it’s as complicated as dealing with a corrupt stack because while allocating an array, you forgot to reserve space for null byte termination. This article discusses reasons behind some common memory leaks and crash.
Dangling pointers:
Dangling pointer is a pointer to an already deallocated heap memory.
First scenario that causes dangling pointer is when an application tries to use object even after it has been released. This causes invalid memory access. For instance:
MyClass *obj1 = new MyClass(); MyClass *obj2 = obj1;After the assignment of obj1 to obj2, both the object point to same heap location.
delete obj2;
Above statement destroys the memory allocated on the heap. So both object pointers obj1 and obj2 exist and are in-scope but they point to undefined storage location. Using obj1 or obj2 will cause undefined behaviour.
Dangling pointers: Return pointer to local variable:
Second scenario that causes dangling pointers is returning pointers to local variables from functions. This is because local variables go out of scope once the functions ends and the pointer becomes invalid. Consider:
MyClass* test()
{
MyClass temp;
return &temp;
}
The function test returns pointer to a local variable ‘temp’ . Once the function goes out of scope, the automatic variable ‘temp’ is destroyed.
MyClass obj = test(); obj.display();
Any attempts to access the return value from test() will have unpredictable results. Variable temp is now out of scope and the memory allocated for temp has already been destroyed.
Another amazing C++ combination, that is a store house of memory leaks, is the deadly char data type and pointers combination.
char* function( char* c)
{
char* temp = new char [ strlen (c) + 1 ];
strcpy ( temp, c );
delete[] c; //evil, should not delete callers string
return temp;
}
int main()
{
char testStr[10] = "CODECALL";
char* retVal = function(testStr);
.....
....
delete retVal; //it is the responsibility of the caller to clear the heap
return 0;
}
Deleting the callers string ‘c’ is evil. Also, code allocates memory on the heap and returns a pointer to it. Now its the callers responsibility to deallocate the memory from the heap else a memory leak will follow.
Deallocating already freed memory:
Trying to delete memory that has already been deallocated again causes undefined behavior.
Accessing an already destroyed memory causes undefined behavior. If the storage has been realloted to another variable, this might imply that some portion of newly allocated memory is being read or being tampered causing the program to crash. In some cases, if the deallocated memory has not been reassigned, attempts to access it might return correct results. In general the program behavior is undefined.
void fun()
{
MyClass * obj = new MyClass();
obj.display()
….
delete obj;
…
…
delete obj;
}
obj has already been deleted. Attempt to delete it again causes undefined behavior.
Null pointer:
Its considered a good programming practice to assign NULL to variables once the memory they point to has been freed:
delete obj; obj = NULL;
This avoids many programming errors as deleting a NULL pointer has no effect.
But be sure not to access methods using the NULL pointer else it might cause unpredictable behavior.
… delete obj; obj = NULL; …. … obj->display(); //if obj is null, program might crash
Buffer overflow:
C++ has no bound checks. So if memory is allotted to a variable for 8bytes but a programmer tries to write in 12bytes to that variable, C++ would permit it. This is known as buffer overflow since the remaining 4 bytes spill over and corrupt the process stack. This might crash the program. Consider the following example:
void bufferTest( char* originalStr)
{
char buf1[10];
char buf2[10];
strcpy(buf2, originalStr);
}
int main()
{
char *testStr = “CODECALL FORUM”;
bufferTest(testStr);
return 0;
}
For the function bufferTest(), a high level view of the stack frame would be like:
The function bufferTest’s argument points to a string of 15bytes. strcpy() does no bound checking and copies this 15bytes to a 10 byte buffer. The remaining 5 bytes spill over and overwrite the stack frame pointer (sfp). This damages the process stack. When the processing of bufferTest() is over and it tries to return, it would get some random address which is either invalid memory location or incorrect memory location. Either ways, the program crashes.
The +1 problem with chars…
Every C++ programmer has atleast once faced the ‘Null Byte Termination Trouble’. The rule of thumb is:
strlen() returns the length up to but not including the null character.
char* testStr = “codecall”; strlen(str) would return 8 though the string is null terminated.
So when creating strings, null char at the end of the string should be taken care of.
For some string str: char * ptr = new char[strlen(str)+1]; strcpy(p,str);
Thanks for staying by and reading…
memory_leak_samples.zip 1.53KB
368 downloads
