What happens with the memory leak?

Question

I really don't understand what happens with allocated memory in a heap when exception occurs:

#include <iostream>
#include <vector>
using namespace std;

class Base {
private:
    int *a;
public:
    Base() {
        // a = new int[100];

        throw runtime_error("err");
    }

    ~Base() {
        // delete[] a;
    }
};

int main() {
    std::vector<Base> bases;
    Base base;
    bases.push_back(base);

    std::cout << bases.size() << std::endl;

    return 0;
}

Okay, now, it is just empty program that throws an exception. The next program, that allocates memory in a heap:

#include <iostream>
#include <vector>
using namespace std;

class Base {
private:
    int *a;
public:
    Base() {
        a = new int[100];

        throw runtime_error("err");
    }

    ~Base() {
        // delete[] a;
    }
};

int main() {
    std::vector<Base> bases;
    Base base;
    bases.push_back(base);

    std::cout << bases.size() << std::endl;

    return 0;
}

Program 1:

==14151== HEAP SUMMARY:
==14151==     in use at exit: 72,876 bytes in 3 blocks
==14151==   total heap usage: 4 allocs, 1 frees, 72,908 bytes allocated
==14151== 
==14151== Searching for pointers to 3 not-freed blocks
==14151== Checked 116,088 bytes
==14151== 
==14151== 144 bytes in 1 blocks are possibly lost in loss record 2 of 3
==14151==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14151==    by 0x4EC641F: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==14151==    by 0x400F44: Base::Base() (in /home/twite/CLionProjects/oop_learn/driver1)
==14151==    by 0x400E25: main (in /home/twite/CLionProjects/oop_learn/driver1)
==14151== 
==14151== LEAK SUMMARY:
==14151==    definitely lost: 0 bytes in 0 blocks
==14151==    indirectly lost: 0 bytes in 0 blocks
==14151==      possibly lost: 144 bytes in 1 blocks
==14151==    still reachable: 72,732 bytes in 2 blocks

Program 2:

==14171== HEAP SUMMARY:
==14171==     in use at exit: 73,276 bytes in 4 blocks
==14171==   total heap usage: 5 allocs, 1 frees, 73,308 bytes allocated
==14171== 
==14171== Searching for pointers to 4 not-freed blocks
==14171== Checked 116,096 bytes
==14171== 
==14171== 144 bytes in 1 blocks are possibly lost in loss record 2 of 4
==14171==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14171==    by 0x4EC641F: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==14171==    by 0x400F98: Base::Base() (in /home/twite/CLionProjects/oop_learn/driver2)
==14171==    by 0x400E65: main (in /home/twite/CLionProjects/oop_learn/driver2)
==14171== 
==14171== LEAK SUMMARY:
==14171==    definitely lost: 0 bytes in 0 blocks
==14171==    indirectly lost: 0 bytes in 0 blocks
==14171==      possibly lost: 144 bytes in 1 blocks
==14171==    still reachable: 73,132 bytes in 3 blocks

So, where's the memory leak? Valgrind doesn't tell me about the memory leak, but i see the one in second program.

Answer 1

When the program terminates the OS cleans up any memory it allocated - not usually a problem. Memory leaks at shutdown are rarely a problem (unless some critically important destructors didn't get a chance to run). Where memory leaks are a real problem is when they happen during runtime and causes your programs memory use to grow unbounded (eventually leading to resource exhaustion).