Valgrind error in C++ memory leak checking

Question

I'm trying to figure out Valgrind usage so I made a simple program but it seems Valgrind gives a strange error when I do dynamic mem allocation in class.

My program is:

class Valgrind_testclass
{
 Valgrind_testclass *Obj;
public:
  Valgrind_testclass() { 
    // Obj = new Valgrind_testclass();  // Test point #3
  }
  ~Valgrind_testclass() {
    //delete Obj;               // Test point #4
  }
};

int main()
{
 Valgrind_testclass valObj;
 // Valgrind_testclass * valObjPtr = new Valgrind_testclass();  // Test point #1
 //delete valObjPtr;                 // Test point #2
 return 0;
}

With commented out test points Valgrind gives me the following:

==5273== HEAP SUMMARY:
==5273==     in use at exit: 0 bytes in 0 blocks
==5273==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated

which I suppose is the expected result.

Now when I uncomment test point #1:

==5288== HEAP SUMMARY:
==5288==     in use at exit: 4 bytes in 1 blocks
==5288==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==5288== 
==5288== Searching for pointers to 1 not-freed blocks
==5288== Checked 102,116 bytes
==5288== 
==5288== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1

which again is the correct result since I'm not performing the deletion.

With test point #2 uncommented I get:

==5300== HEAP SUMMARY:
==5300==     in use at exit: 0 bytes in 0 blocks
==5300==   total heap usage: 1 allocs, 1 frees, 4 bytes allocated
==5300== 
==5300== All heap blocks were freed -- no leaks are possible

Again correct result.

Now I uncomment test point #3, and I expect Valgrind to detect the memory leak. This is what I get:

==5313== Process terminating with default action of signal 11 (SIGSEGV)
==5313==  Access not within mapped region at address 0xBE17AFE4
==5313==    at 0x40263A0: operator new(unsigned int) (vg_replace_malloc.c:255)
==5313==  If you believe this happened as a result of a stack
==5313==  overflow in your program's main thread (unlikely but
==5313==  possible), you can try to increase the size of the
==5313==  main thread stack using the --main-stacksize= flag.
==5313==  The main thread stack size used in this run was 8388608.
==5313== Stack overflow in thread 1: can't grow stack to 0xbe17afe0
==5313== 
==5313== Process terminating with default action of signal 11 (SIGSEGV)
==5313==  Access not within mapped region at address 0xBE17AFE0
==5313==    at 0x402040C: _vgnU_freeres (vg_preloaded.c:58)
==5313==  If you believe this happened as a result of a stack
==5313==  overflow in your program's main thread (unlikely but
==5313==  possible), you can try to increase the size of the
==5313==  main thread stack using the --main-stacksize= flag.
==5313==  The main thread stack size used in this run was 8388608.
==5313== 
==5313== HEAP SUMMARY:
==5313==     in use at exit: 1,047,576 bytes in 261,894 blocks
==5313==   total heap usage: 261,894 allocs, 0 frees, 1,047,576 bytes allocated
==5313== 
==5313== Searching for pointers to 261,894 not-freed blocks
==5313== Checked 5,339,952 bytes
==5313== 
==5313== LEAK SUMMARY:
==5313==    definitely lost: 0 bytes in 0 blocks
==5313==    indirectly lost: 0 bytes in 0 blocks
==5313==      possibly lost: 0 bytes in 0 blocks
==5313==    still reachable: 1,047,576 bytes in 261,894 blocks
==5313==         suppressed: 0 bytes in 0 blocks
==5313== Reachable blocks (those to which a pointer was found) are not shown.
==5313== To see them, rerun with: --leak-check=full --show-reachable=yes
==5313== 
==5313== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 6)

I'm not sure why I'm not seeing a similar memory leak error here. Could somebody please help in understanding this situation, whether I'm doing something wrong. The Valgrind command I use is:

valgrind -v --tool=memcheck --leak-check=full --num-callers=40  ./ValgrindOutput 

Thank you.

Answer 1

This is because you have infinite recursion

Valgrind_testclass is new'ing a Valgrind_testclass which is new'ing another Valgrind_testclass ...ad infinitum

Answer 2

The program hasn't ended properly. What you are looking at is a stack overflow error.

The constructor does new Valgrind_testclass(), which calls the constructor. Infinite recursion!