c++ - 即使我不执行动态分配，Valgrind 也会报告映射中的内存泄漏

Question

我已经跑了 valgrind和 AddressSanitizer 在我做的一个大项目中，他们都报告我使用的许多 map 存在内存泄漏。但是，我在程序中没有使用动态内存分配(没有调用 new()，也没有使用指针(甚至没有智能指针)，只有引用)。

不幸的是，原始代码太大并且处于保密条款之下，所以我不能在这里完全分享。我试图创建一个最小的复制品，但我没有成功。

基本上我的代码库周围的许多 map 都被认为泄漏了。

以这段代码为例，我在其中创建了一个新 map ，其条目是前一个 map 相同条目中​​值的平均值 std::map<WAL_Processed_Key, std::vector<double> > tmp_map :

{
    std::map<WAL_Processed_Key, std::vector<double> > tmp_map
    ...

    std::map<WAL_Processed_Key, double> 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提示说:

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<std::_Rb_tree_node<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > >::allocate(unsigned long, void const*) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42d7a7)
    #2 0x7f08f6dc412f in std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > > >::allocate(std::allocator<std::_Rb_tree_node<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > >&, unsigned long) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42d12f)
    #3 0x7f08f6dc3574 in std::_Rb_tree<mns::WAL_Map::WAL_Processed_Key, std::pair<mns::WAL_Map::WAL_Processed_Key const, double>, std::_Select1st<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> >, std::less<mns::WAL_Map::WAL_Processed_Key>, std::allocator<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > >::_M_get_node() (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42c574)
    #4 0x7f08f6dc1c48 in std::_Rb_tree_node<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> >* std::_Rb_tree<mns::WAL_Map::WAL_Processed_Key, std::pair<mns::WAL_Map::WAL_Processed_Key const, double>, std::_Select1st<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> >, std::less<mns::WAL_Map::WAL_Processed_Key>, std::allocator<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > >::_M_create_node<std::piecewise_construct_t const&, std::tuple<mns::WAL_Map::WAL_Processed_Key const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple<mns::WAL_Map::WAL_Processed_Key const&>&&, std::tuple<>&&) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42ac48)
    #5 0x7f08f6dc005c in std::_Rb_tree_iterator<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > std::_Rb_tree<mns::WAL_Map::WAL_Processed_Key, std::pair<mns::WAL_Map::WAL_Processed_Key const, double>, std::_Select1st<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> >, std::less<mns::WAL_Map::WAL_Processed_Key>, std::allocator<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<mns::WAL_Map::WAL_Processed_Key const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> >, std::piecewise_construct_t const&, std::tuple<mns::WAL_Map::WAL_Processed_Key const&>&&, std::tuple<>&&) (/home/idgc/project-share/mns/common_lib/Debug/libmns.so+0x42905c)
    #6 0x7f08f6dbed1a in std::map<mns::WAL_Map::WAL_Processed_Key, double, std::less<mns::WAL_Map::WAL_Processed_Key>, std::allocator<std::pair<mns::WAL_Map::WAL_Processed_Key const, double> > >::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<mns::WAL_Key, double, std::less<mns::WAL_Key>, std::allocator<std::pair<mns::WAL_Key const, double> > >, double, boost::optional<double>) ../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通过 const 引用传递以构造一个新的 WAL_Map并且超出范围，因此应该自动调用其析构函数并释放内部内存。

同样，程序中的任何地方(当然在 STL 内部之外)都没有动态分配或使用指针，所以我无法真正解释“泄漏”，特别是因为它们是由两种不同的工具报告的。只有(某些) map 在泄漏，我使用了几个 set s 和 vector围绕代码，它们似乎不是问题。

我知道valgrind有时会报告误报(我不确定 AddressSanitizer )，我的问题似乎类似于 this answer .然而，export GLIBCXX_FORCE_NEW对报告没有影响。

所以我的问题是:如果不使用指针或内存分配，是否会出现内存泄漏(假设 STL 中没有错误，这会令人惊讶)？有没有办法证明这些是误报？

环境:

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

Answer 1

解决了!问题是 operator< map 的关键没有提供strict weak ordering (有关详细信息，请参阅 this StackOverflow question)。

我有这样的东西:

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;
    }
};

当我应该有这样的事情时:

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;
    }
};

当比较运算符不提供严格的弱排序时，遍历映射会以意想不到的方式运行(例如，映射可能会报告 map.size() 大于其 std::distance(map.begin(), map.end()) )。我的假设是，由于错误的比较实现， map 的析构函数无法访问其所有内部元素以进行删除。