Does this produce a memory leak?

Question

I'm following a book on C++ programming, and I'm following the exercises. One exercise asks me to create a program that produces a memory leak. Will this program produce such a leak?

int main()
{
    int * pInt =  new int;
    *pInt = 20;

    pInt = new int;
    *pInt =50;

    return 0;
}

Answer 1

One exercise asks me to create a program that produces a memory leak. 

Will this program produce such a leak?

an utter exercise , and your code is a better answer to exercise !

Pointers and memory leaks. These are truly the items that consume most of the debugging time for developers

Memory leak

Memory leaks can be really annoying. The following list describes some scenarios that result in memory leaks.

Reassignment,  I'll use an example to explain reassignment.

char *memoryArea = malloc(10);
char *newArea = malloc(10);

This assigns values to the memory locations shown in Figure 4 below.

http://www.ibm.com/developerworks/aix/library/au-toughgame/fig4.gif Figure 4. Memory locations

memoryArea and newArea have been allocated 10 bytes each and their respective contents are shown in Figure 4. If somebody executes the statement shown below (pointer reassignment )

memoryArea = newArea; 

then it will surely take you into tough times in the later stages of this module development.

In the code statement above, the developer has assigned the memoryArea pointer to the newArea pointer. As a result, the memory location to which memoryArea was pointing to earlier becomes an orphan, as shown in Figure 5 below. It cannot be freed, as there is no reference to this location. This will result in a memory leak of 10 bytes.

http://www.ibm.com/developerworks/aix/library/au-toughgame/fig5.gif Figure 5. Memory leak

Before assigning the pointers, make sure memory locations are not becoming orphaned.
Freeing the parent block first

Suppose there is a pointer memoryArea pointing to a memory location of 10 bytes. The third byte of this memory location further points to some other dynamically allocated memory location of 10 bytes, as shown in Figure 6.

http://www.ibm.com/developerworks/aix/library/au-toughgame/fig6.gif Figure 6. Dynamically allocated memory

free(memoryArea)

**If memoryArea is freed by making a call to free, then as a result the newArea pointer also will become invalid. The memory location to which newArea was pointing cannot be freed, as there is no pointer left pointing to that location. In other words, the memory location pointed by newArea becomes an orphan and results in memory leak.

Whenever freeing the structured element, which in turn contains the pointer to dynamically allocated memory location, first traverse to the child memory location (newArea in the example) and start freeing from there, traversing back to the parent node. The correct implementation here will be: free( memoryArea->newArea); free(memoryArea); Improper handling of return values At time, some functions return the reference to dynamically allocated memory. It becomes the responsibility of the calling function to keep track of this memory location and handle it properly.**

char *func ( )
{
        return malloc(20); // make sure to memset this location to ‘\0’…
}

void callingFunc ( )
{
        func ( ); // Problem lies here
}

In the example above, the call to the func() function inside the callingFunc() function is not handling the return address of the memory location. As a result, the 20 byte block allocated by the func() function is lost and results in a memory leak.

Sharp Reference at : http://www.ibm.com/developerworks/aix/library/au-toughgame/

Update: your interest let me for an edit

Simple rules to avoid Memory Leaks in C

You are allocating memory for p and q:

p=new int [5];
/* ... */
q=new int;

But you are only freeing p using an invalid operator, since arrays should be deleted using delete[]. You should at some point free both p and q using:

delete[] p;
delete q;

Note that since you are making your pointers point to the other pointer's allocated buffer, you might have to check which delete operator corresponds to which new operation.

You should use delete[] on the buffer allocated with new[] and delete with the buffer allocated with new.

Rule 1: Always write “free” just after “malloc”

int *p = (int*) malloc ( sizeof(int) * n );

free (p);

Rule 2: Never, ever, work with the allocated pointer. Use a copy!

int *p_allocated = (int*) malloc ( sizeof(int) * n );

int *p_copy = p_allocated;

// do your stuff with p_copy, not with p_allocated!

// e.g.:

while (n--) { *p_copy++ = n; }

...

free (p_allocated);

Rule 3: Don’t be parsimonious. Use more memory.

Always start by allocating more memory than you need. After you finish debugging, go back and cut on memory use. If you need an array 1000 integers long, allocate 2000, and only after you make sure everything else is OK – only then go back and cut it down to 1000.

Rule 4: Always carry array length along with you

Wherever your array goes, there should go with it it’s length. A nice trick is to allocate an array sized n+1, and save n into it’s 0 place:

int *p_allocated = (int*) malloc ( sizeof(int) * (n+1) );
int *p_copy = p_allocated+1;
p_copy[-1] = n;
// do your stuff with p_copy, not with p_allocated!
free (p_allocated);

Rule 5: Be consistent. And save comments

The most important thing is to be consistent and to write down what you do. I am always amazed at how many programmers seem to think that comments are a waste of time. They are imperative. Without comments, you probably won’t remember what you did. Imagine returning to your code a year after you wrote it, and spending countless hour trying to recall what that index does. Better to spend a couple of seconds writing it down.

Also, if you are consistent, you will not fail often. Always use the same mechanism for passing arrays and pointers. Don’t change the way you do things lightly. If you decide to use my previous trick, use it everywhere, or you might find yourself referring back to a nonexistent place because you forgot what type of reference you chose.

Ref : http://mousomer.wordpress.com/2010/11/03/simple-rules-to-avoid-memory-leaks-in-c/

Answer 2

Considering it is a trivial example, not having a delete paired with your new is a leak. In order to prevent a leak in this case you would need the following:

int * pInt =  new int;
*pInt = 20;

delete pInt ;

pInt = new int;
*pInt =50;

delete pInt ;

A decent tool to use to detect memory leaks is Valgrind. I ran the tool on your sample code, like so:

 valgrind ./a.out

and this is part of the output it produced:

==14153== HEAP SUMMARY:
==14153==     in use at exit: 8 bytes in 2 blocks
==14153==   total heap usage: 2 allocs, 0 frees, 8 bytes allocated
==14153== 
==14153== LEAK SUMMARY:
==14153==    definitely lost: 8 bytes in 2 blocks

Which confirms that indeed the program does leak memory.

Answer 3

It does, because you allocate space with the statement "new int", but do not use "delete" to free the space.

Answer 4

Yes and no. When pInt is overwritten with a new int pointer, you lose that memory that was previously allocated, however when the program returns, most modern operating systems will clean up this memory, as well as the memory lost by not deallocating pInt at the end.

So in essence, yes, something like this will result in two memory leaks.

Answer 5

Yes. To avoid leaks, every time you call new, you have to have a matching call to delete. You have 2 calls to new and no calls to delete, so you have 2 leaks.

Note that when your program exits, the OS will free up all the memory you've allocated with new. So memory leaks are really only a problem for non-trivial programs.

Answer 6

Will this program produce suck a leak?

Yes, it will.

Answer 7

Yes, this produces not one, but two memory leaks: both allocated ints are leaked. Moreover, the first one is leaked irrecoverably: once you assign pInt a new int the second time, the first allocated item is gone forever.