Does this code cause memory leak?

Question

I am curious if this code causes memory leak probably due to the fact that I reassign the pointer at line 3 before deleting it at line 4??

Thanks.

1. int y = 12;
2. int *pt = new int;
3. pt = &y;
4. delete pt; 

Answer 1

It not only leaks the dynamically allocated int but also has undefined behaviour, because you can't delete an object that wasn't allocated with new (§5.3.5/2).

the value of the operand of delete may be a null pointer value, a pointer to a non-array object created by a previous new-expression , or a pointer to a subobject (1.8) representing a base class of such an object (Clause 10). If not, the behavior is undefined.

Since the object denoted by y was not allocated with a new-expression , you cannot use delete to destroy it. Its lifetime is governed by its scope.

Answer 2

Whenever you are not sure about memory leaks in your code, you can use valgrind valgrind --tool=memcheck to check for them, but be sure to compile the code without any optimization and in full debug mode (eg "g++ -g").

Here is the output for your program:

=29667== Memcheck, a memory error detector
==29667== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==29667== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==29667== Command: ./main
==29667== 
==29667== Invalid free() / delete / delete[]
==29667==    at 0x4C26DCF: operator delete(void*) (vg_replace_malloc.c:387)
==29667==    by 0x4006AB: main (main.cpp:7)
==29667==  Address 0x7fefffd0c is on thread 1's stack
==29667== 
==29667== 
==29667== HEAP SUMMARY:
==29667==     in use at exit: 4 bytes in 1 blocks
==29667==   total heap usage: 1 allocs, 1 frees, 4 bytes allocated
==29667== 
==29667== LEAK SUMMARY:
==29667==    definitely lost: 4 bytes in 1 blocks
==29667==    indirectly lost: 0 bytes in 0 blocks
==29667==      possibly lost: 0 bytes in 0 blocks
==29667==    still reachable: 0 bytes in 0 blocks
==29667==         suppressed: 0 bytes in 0 blocks
==29667== Rerun with --leak-check=full to see details of leaked memory
==29667== 
==29667== For counts of detected and suppressed errors, rerun with: -v
==29667== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

Your code looses 4 bytes at exit().

Here is the list of stuff you can do with memcheck, from the tool's website

Memcheck is a memory error detector. It can detect the following problems that are common in C and C++ programs.

• Accessing memory you shouldn't, eg overrunning and underrunning heap blocks, overrunning the top of the stack, and accessing memory after it has been freed.

• Using undefined values, ie values that have not been initialised, or that have been derived from other undefined values.

• Incorrect freeing of heap memory, such as double-freeing heap blocks, or mismatched use of malloc/new/new[] versus free/delete/delete[]

  • Overlapping src and dst pointers in memcpy and related functions.

  • Memory leaks.

Problems like these can be difficult to find by other means , often remaining undetected for long periods, then causing occasional, difficult-to-diagnose crashes.

Answer 3

It would cause a memory leak if it didn't first likely cause a crash.

You shouldn't delete an object that has 'automatic' storage.

Answer 4

Yes.

The moment you lost the pointer to the new int you leaked

pt = &y; // Here the memory allocated is not reachable now and can not be deleted 

And this is UB

delete pt;  // pt is pointing to automaticaly allocated memory now. You can't delete that.

Answer 5

It should crash, because you assing a stack adress to your pointer and then delete it. At least it's undefined what happens.

Answer 6

Yes, it does indeed cause a memory leak because the subsequent assignment of pt causes you to lose the previous assignment that contained the memory. If you had called delete pt before that, it would have been fine.