Valgrind memory leak detection - memory-leaks

Question

I am new to Valgrind, and I wanted to see how valgrind works. I wrote a sample program for memory leak. However Valgrind does not seem to detect a memory leak. Can you please tell me why? Or does the below code leak memory?
#include <iostream>
using namespace std;
class test {
private:
int a;
public:
test(int c) {
a = c;
}
};
int main() {
test* t = new test(7);
}
this is the valgrind output
HEAP SUMMARY:
==5449== in use at exit: 0 bytes in 0 blocks
==5449== total heap usage: 29 allocs, 29 frees, 3,592 bytes allocated
==5449==
==5449== All heap blocks were freed -- no leaks are possible

Answer 1

I don't think that constitutes a memory leak; the memory at pointer t is not 'lost' until t goes out of scope, and that's at the end of main() so there's no memory loss.
dan#rachel ~ $ g++ -o t t.cpp
dan#rachel ~ $ valgrind ./t
==11945== Memcheck, a memory error detector
==11945== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==11945== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11945== Command: ./t
==11945==
==11945==
==11945== HEAP SUMMARY:
==11945== in use at exit: 36 bytes in 9 blocks
==11945== total heap usage: 9 allocs, 0 frees, 36 bytes allocated
==11945==
==11945== LEAK SUMMARY:
==11945== definitely lost: 36 bytes in 9 blocks
==11945== indirectly lost: 0 bytes in 0 blocks
==11945== possibly lost: 0 bytes in 0 blocks
==11945== still reachable: 0 bytes in 0 blocks
==11945== suppressed: 0 bytes in 0 blocks
==11945== Rerun with --leak-check=full to see details of leaked memory
==11945==
==11945== For counts of detected and suppressed errors, rerun with: -v
==11945== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
The code was modified slightly to use test* t multiple times in a for loop, effectively "forgetting" all but the last test object.
#include <iostream>
using namespace std;
class test {
private:
int a;
public:
test(int c){
a = c;
}
};
int main(){
test* t;
for(int i=1; i<10;i++)
t=new test(i);
}
For even better memory leak patching, try compiling with debugging information and using the valgrind option recommended in the output:
dan#rachel ~ $ g++ -g -o t t.cpp
dan#rachel ~ $ valgvalgrind --leak-check=full ./t
==11981== Memcheck, a memory error detector
==11981== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==11981== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11981== Command: ./t
==11981==
==11981==
==11981== HEAP SUMMARY:
==11981== in use at exit: 36 bytes in 9 blocks
==11981== total heap usage: 9 allocs, 0 frees, 36 bytes allocated
==11981==
==11981== 36 bytes in 9 blocks are definitely lost in loss record 1 of 1
==11981== at 0x4C2C099: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11981== by 0x4006EF: main (t.cpp:15)
==11981==
==11981== LEAK SUMMARY:
==11981== definitely lost: 36 bytes in 9 blocks
==11981== indirectly lost: 0 bytes in 0 blocks
==11981== possibly lost: 0 bytes in 0 blocks
==11981== still reachable: 0 bytes in 0 blocks
==11981== suppressed: 0 bytes in 0 blocks
==11981==
==11981== For counts of detected and suppressed errors, rerun with: -v
==11981== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

Answer 2

Try allocating t to another test object - i.e.
int main() {
test* t = new test(7);
t = new test(7);
t = new test(8); // and so on...
}
I believe each time t is assigned to another memory location, without freeing the previously allocated memory will constitute a leak (unless your compiler is smart enough to see that the allocated memory is never used and does something clever -- in which case, be doubly certain by creating some sample variables that use t , before reassigning t and maybe even return one of those variables...)