Chapter 13

Common Memor y Pitfalls

It is difficult to pinpoint the exact situations that can lead to a memory-related bug. Every memory leak or bad pointer has its own nuances. There is no magic bullet for resolving memory issues, but there are several common categories of problems and some tools you can use to detect and resolve them.

Underallocating Strings

As you read above, the most common problem with C-style strings is underallocation. In most cases, this arises when the programmer fails to allocate an extra character for the trailing ‘\0’ sentinel. Underallocation of strings also occurs when programmers assume a certain fixed maximum size. The basic built-in string functions will not adhere to a fixed size — they will happily write off the end of the string into uncharted memory.

The following code reads data off a network connection and puts it in a C-style string. This is done in a loop because the network connection only receives a small amount of data at a time. When NULL is returned from the getMoreData() function, all of the data has been received.

while (!done) {

char* nextChunk = getMoreData(); if (nextChunk == NULL) {

done = true; } else {

strcat(buffer, nextChunk); // BUG! No guarantees against buffer overrun! delete[] nextChunk;

}

}

There are three ways to resolve this problem. In increasing order of preference, they are:

1.Find a version of getMoreData() that takes a maximum size as a parameter. Each time you call getMoreData(), only give it the amount of space that you have left as the maximum size.

2.Keep track of how much space is left in the buffer. When it is no longer big enough for the current chunk, allocate a new buffer with twice as much space and copy the original buffer into the new buffer.

3.Use C++-style strings, which will handle the memory associated with concatenation on your behalf. That’s right, let it go!

Memory Leaks

Finding and fixing memory leaks is one of the more frustrating parts of programming in C++. Your program finally works and appears to give the correct results. Then, you start to notice that your program gobbles up more and more memory as it runs. Your program has a memory leak.

Memory leaks occur when you allocate memory and neglect to release it. At first, this sounds like the result of careless programming that could easily be avoided. After all, if every new has a corresponding delete in every class you write, there should be no memory leaks, right? Actually, that’s not always

374

Effective Memory Management

true. In the following code, the Simple class is properly written to release any memory that it allocates. However, when the doSomething() function is called, the pointer is changed to another Simple object without deleting the old one. Once you lose a pointer to an object, it’s nearly impossible to delete it.

#include <iostream>

using namespace std;

class Simple

{

public:

Simple() { mIntPtr = new int(); } ~Simple() { delete mIntPtr; }

void setIntPtr(int inInt) { *mIntPtr = inInt; } void go() { cout << “Hello there” << endl; }

protected:

int* mIntPtr;

};

void doSomething(Simple*& outSimplePtr)

{

outSimplePtr = new Simple(); // BUG! Doesn’t delete the original.

}

int main(int argc, char** argv)

{

Simple* simplePtr = new Simple(); // Allocate a Simple object.

doSomething(simplePtr);

delete simplePtr; // Only cleans up the second object

}

In cases like the preceding example, the memory leak probably arose from poor communication between programmers or poor documentation of code. The caller of doSomething() may not have realized that the variable was passed by reference and thus had no reason to expect that the pointer would be reassigned. If they did notice that the parameter is a non-const reference to a pointer, they may have suspected that something strange was happening, but there is no comment around doSomething() that explains this behavior.

Finding and Fixing Memory Leaks

Memory leaks are hard to track down because you can’t easily look at memory and see what objects are not in use and where they were originally allocated. Luckily, there are programs that can do this for you. Memory leak detection tools range from expensive professional software packages to free downloadable tools. One such free tool is valgrind, an open-source tool for Linux that, amongst other things, pinpoints the exact line in your code where a leaked object was allocated.

The following output, generated by running valgrind on the previous program, pinpoints the exact location where memory was allocated but never released. In this case, there were two leaks — the first Simple object that was never deleted and the heap-based integer that it created.

375

Chapter 13

==15606== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==15606== Copyright (C) 2002-2003, and GNU GPL’d, by Julian Seward.

==15606== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==15606== Copyright (C) 2000-2003, and GNU GPL’d, by Julian Seward.

==15606== Estimated CPU clock rate is 1136 MHz ==15606== For more details, rerun with: -v ==15606== ==15606==

==15606== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==15606== malloc/free: in use at exit: 8 bytes in 2 blocks.

==15606== malloc/free: 4 allocs, 2 frees, 16 bytes allocated. ==15606== For counts of detected errors, rerun with: -v ==15606== searching for pointers to 2 not-freed blocks. ==15606== checked 4455600 bytes.

==15606==

==15606== 4 bytes in 1 blocks are still reachable in loss record 1 of 2

Of course, programs like valgrind can’t actually fix the leak for you — what fun would that be? These tools provide information that you can use to find the actual problem. Normally, that involves stepping through the code to find out where the pointer to an object was overwritten without the original object being released. Some debuggers provide “watch point” functionality that can stop execution of the program when this occurs.

Smart Pointers

An increasingly popular technique for avoiding memory leaks is the use of smart pointers. Smart pointers are a notion that arose from the fact that most memory-related issues are avoidable by putting everything on the stack. The stack is much safer than the heap because stack variables are automatically destructed and cleaned up when they go out of scope. Smart pointers combine the safety of stack variables with the flexibility of heap variables.

The theory behind a smart pointer is quite simple: it is an object with an associated pointer. When the smart pointer goes out of scope, the associated pointer is deleted. It essentially wraps a heap object inside of a stack-based object.

376

Effective Memory Management

The C++ standard template library includes a basic implementation of a smart pointer, called auto_ptr. Instead of storing dynamically allocated objects in pointers, you can store them in stack-based instances of auto_ptr. You won’t need to explicitly release memory associated with an auto_ptr — it will get cleaned up when the auto_ptr goes out of scope.

As an example, consider the following function that blatantly leaks memory by allocating a Simple object on the heap and neglecting to release it.

void leaky()

{

Simple* mySimplePtr = new Simple(); // BUG! Memory is never released!

mySimplePtr->go();

}

Using the auto_ptr class, the object still is not explicitly deleted. However, when the auto_ptr object goes out of scope (at the end of the method) it releases the Simple object in its destructor.

void notLeaky()

{

auto_ptr<Simple> mySimpleSmartPtr(new Simple());

mySimpleSmartPtr->go();

}

One of the greatest characteristics of smart pointers is that they provide enormous benefit without requiring the user to learn a lot of new syntax. As you can see in the preceding code, the smart pointer can still be dereferenced (using * or ->) just like a standard pointer.

Chapter 16 provides an actual implementation of a smart pointer template class through operator overloading. Chapter 25 describes an enhanced implementation of smart pointers that includes reference counting.

Double-Deleting and Invalid Pointers

Once you release memory associated with a pointer using delete, the memory is available for use by other parts of your program. Nothing stops you, however, from attempting to continue to use the pointer. Double deletion is also a problem. If you use delete a second time on a pointer, the program could be releasing memory that has since been assigned to another object.

Double deletion and use of already released memory are both hard problems to track down because the symptoms may not show up immediately. If two deletions occur within a relatively short amount of time, the program might work indefinitely because the associated memory is not reused that quickly. Similarly, if a deleted object is used immediately after being deleted, most likely it will still be intact.

Of course, there is no guarantee that such behavior will work or continue to work. The memory allocator is under no obligation to preserve any object once it has been deleted. Even if it does work, it is extremely poor programming style to use objects that have been deleted.

Many memory leak checking programs, such as valgrind, will also detect double deletion and use of released objects.

377