Why does Valgrind report a memory leak in this implementation?

Question

I have the following piece of C++ code, wherein I'm trying to execute a routine:

#include <thread>
#include <unistd.h>
#include <sys/wait.h>
#include <memory>

using namespace std;

static void upload(const string url, const string path){ int sync_status;}

int main(){
    bool flag = true;
    for(int worker_id = 0; worker_id < 1; worker_id++){
        int worker_pid = fork();
        if (worker_pid == 0){
            while (true){
                std::unique_ptr<std::thread> uploader(nullptr);
                if (flag){       // This block only occurs once inside while loop
                    flag = false;
                    string path = "l", url = "k";
                    // Valgrind reports the next line
                    uploader = std::make_unique<std::thread>(upload, url, path);
                }
                int child_id = fork();
                if (!child_id){
                    // Do something
                    exit(0);
                }
                waitpid(child_id, NULL, 0);
                if(uploader && uploader->joinable()){
                    uploader->join();
                }
            }
            // Do something
            exit(0);
        }
    }
    return 0;
}

But valgrind seems to always report this code as follows:

==16424== 80 bytes in 1 blocks are definitely lost in loss record 2 of 2
==16424==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16424==    by 0x10AA39: std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> > std::thread::_S_make_state<std::thread::_Invoker<std::tuple<void (*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >(std::thread::_Invoker<std::tuple<void (*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&&) (thread:197)
==16424==    by 0x10A04A: std::thread::thread<void (&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&>(void (&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (thread:126)
==16424==    by 0x109A64: std::_MakeUniq<std::thread>::__single_object std::make_unique<std::thread, void (&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&>(void (&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (unique_ptr.h:825)
==16424==    by 0x109514: main (main.cpp:21)

what is the reason behind this leak? I thought that this was due to the exit() call but even joining the unique_ptr before the call does not help.

Answer 1

You can find this sentence in [basic.start.main]:

Terminating the program without leaving the current block (e.g., by calling the function std​::​exit(int) ([support.start.term])) does not destroy any objects with automatic storage duration ([class.dtor]).

So your forked copy of the unique_ptr will never be destroyed. That is the leak valgrind reports.

Not that trying to destroy two copies of a unique_ptr seems like a great idea either. So there is probably a deeper flaw in the design of this example.