Question

Edit: To anyone reading this question for future use: the error had not to do with unique_ptr by any means. It was simply, as JoergB justly says in his answer, a mistake on my part to forget a virtual destructor for a base class.

---

After the occasional run-time crash, I figured my code was suffering from a severe case of memory-leak-itis. I ran my program with Valgrind and the doctor seems to agree: bytes are definitely lost. I can’t for the life of me figure out where it goes wrong, though.

I managed to pin the leak down into happening in these three lines:

std::unique_ptr<Operator> pointer(new Operator{"left", "right"});
NodeSpace space; // The node space takes ownership over the operator

// When I comment out the following line, Valgrind reports nothing:
space.setNode("key", move(pointer));

In the first line a unique_pointer is created, holding an instance of the Operator class. The Operator internally looks like this:

class Operator : public Node {
public:
    Operator(std::initializer_list<std::string> input_keys) {
        input_nodes_.reserve(input_keys.size());
        for_each(begin(input_keys), end(input_keys), [this](const string& key) {
            input_nodes_[key] = nullptr;
        });
    }

    // ...

private:
    std::unordered_map<std::string, Node*> input_nodes_;
};

I pass in the unique_ptr r-value reference to the following function:

void NodeSpace::setNode(const std::string& key, std::unique_ptr<Node> node);

Because the node space takes over ownership of the passed-in node, it takes a unique_ptr by value (move semantics). Internally it stores the pointer in an std::map, but even if the function body is commented out, the memory leak still happens (which leads me to believe the problem is the node argument of the function call).

Anyone know remotely where the problem could be?

Sidenote: I’m not using shared_ptr, because the nodes can refer to each other in a cyclic manner. weak_ptr could be an option, but by construction of the system it is impossible for a node to exist when its owning nodespace does not anymore.

Valgrind output:

==83791== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 606 of 794
==83791==    at 0x100060ABD: malloc (vg_replace_malloc.c:274)
==83791==    by 0x1000C9147: operator new(unsigned long) (in /usr/lib/libc++.1.dylib)
==83791==    by 0x10000CB0F: std::__1::__hash_table<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*> > >::__rehash(unsigned long) (in ./test/mimi)
==83791==    by 0x10000C684: std::__1::__hash_table<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*> > >::rehash(unsigned long) (in ./test/mimi)
==83791==    by 0x100005D5A: mimi::Operator::Operator(std::initializer_list<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >) (in ./test/mimi)
==83791==    by 0x100005984: mimi::Operator::Operator(std::initializer_list<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >) (in ./test/mimi)
==83791==    by 0x10002E940: main (in ./test/mimi)

I also don’t get why Valgrind seems to tell me the leak happens in the Operator constructor, even though the operator has already been constructed by the time NodeSpace::setNode() is called.

Answer 1

You don’t show us key pieces of the code – the declaration of Node, in particular its destructor, parts of NodeSpace, in particular how it deletes Nodes, etc. But from your comment “Neither Node nor Operator have any destructor and copy/move constructor/assignment-operator”, it appears that that is the problem.

If you maintain ownership of an Operator through a Node * or a unique_ptr<Node>, i.e. if you delete any derived objects through a Node *, Node must have a virtual destructor. If you don’t declare and define one, it doesn’t.

While the resulting behavior is undefined, the outcome typically is, that destructors of members of the derived class are not called. That matches your error message.