Valgrind reports memory leak in map even when I don't perform dynamic allocations

Question

I've run valgrind and AddressSanitizer on a big project I've made and they both report memory leaks in many maps I use. However, I use no dynamic memory allocation in the program (no calls to new() are made, and no pointers (not even smart pointers) are ever used either, only references).

Unfortunately, the original code is too big and is under a confidentiality clause, so I can't really share it fully here. I have tried to create a minimal reproduction, but I was not successful.

Basically many maps around my code base are supposedly leaking.

Take this code, for example, in which I create a new map whose entries are the average of the values in those same entries of a previous map std::map > tmp_map:

{
    std::map > tmp_map
    ...

    std::map reduced_map;

    for (auto const& entry : tmp_map)
    {
        reduced_map[entry.first]      // Line 98
            = std::accumulate(
                entry.second.begin(),
                entry.second.end(), 0.0) / entry.second.size();
    }

    return WAL_Map(
            reduced_map, start, end, time_granularity, grid_size);
}

AddressSanitizer complains that:

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x7f08f7978532 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99532)
    #1 0x7f08f6dc47a7 in __gnu_cxx::new_allocator > >::allocate(unsigned long, void const*) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42d7a7)
    #2 0x7f08f6dc412f in std::allocator_traits > > >::allocate(std::allocator > >&, unsigned long) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42d12f)
    #3 0x7f08f6dc3574 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_get_node() (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42c574)
    #4 0x7f08f6dc1c48 in std::_Rb_tree_node >* std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_create_node, std::tuple<> >(std::piecewise_construct_t const&, std::tuple&&, std::tuple<>&&) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42ac48)
    #5 0x7f08f6dc005c in std::_Rb_tree_iterator > std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_emplace_hint_unique, std::tuple<> >(std::_Rb_tree_const_iterator >, std::piecewise_construct_t const&, std::tuple&&, std::tuple<>&&) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42905c)
    #6 0x7f08f6dbed1a in std::map, std::allocator > >::operator[](mns::WAL_Map::WAL_Processed_Key const&) /usr/include/c++/5/bits/stl_map.h:483
    #7 0x7f08f6dbd886 in mns::WAL_Map::reduce_map(std::map, std::allocator > >, double, boost::optional) ../Types/WAL_Map.cpp:98
    #8 0x4ef2f3 in mns::PMS_Algorithm_Manager::process() ../PMS_Algorithm_Manager.cpp:223
    #9 0x54ce7c in main ../main.cpp:262
    #10 0x7f08f5d4c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

reduced_map is passed by const reference to construct a new WAL_Map and the goes out of scope, so its destructor should be automatically invoked and the internal memory freed.

Again, there is no dynamic allocation or use of pointers anywhere in the program (outside STL's internals, of course), so I can't really explain the "leaks", particularly as they are reported by two different tools. Only (certain) maps are leaking, I use several sets and vectors around the code and they don't seem to be a problem.

I know valgrind sometimes reports false positives (I'm not sure about AddressSanitizer), and my issue seems similar to this answer. However, export GLIBCXX_FORCE_NEW made no difference in the reports.

So my questions are: can there be memory leaks if no pointers or memory allocations are used (assuming no bugs in STL, which would be suprising)? Is there a way to prove that these are false positives?

Environment:

Ubuntu 16.04.2 LTS
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
glibc 2.23

user2891462 · Accepted Answer

Solved it! The issue was that the operator< of the map's key did not provide strict weak ordering (see this StackOverflow question for more information).

I had something like this:

struct WAL_Processed_Key
{
    int foo;
    int bar;
    bool operator<(const WAL_Processed_Key& o)
    {
        // Bad implementation, no strict weak ordering!
        return foo < o.foo || bar < o.bar;
    }
};

When I should have had something like this:

struct WAL_Processed_Key
{
    int foo;
    int bar;
    bool operator<(const WAL_Processed_Key& o)
    {
        if (foo < o.foo) return true;
        if (o.foo < foo) return false;
        if (bar < o.bar) return true
        if (o.bar < bar) return false;
        return false;
    }
};

When the comparison operator does not provide strict weak ordering, iterating over the map behaves in unexpected ways (a map can report a map.size() greater than its std::distance(map.begin(), map.end()), for example). My assumption is that the map's destructor cannot access all its internal elements for deletion due to the faulty comparison implementation.

Valgrind reports memory leak in map even when I don't perform dynamic allocations

Answers (1)

Related Questions

Valgrind reports memory leak in map even when I don&#39;t perform dynamic allocations

Answers (1)

Related Questions

Valgrind reports memory leak in map even when I don't perform dynamic allocations