動的割り当てを実行していなくても、Valgrindはマップのメモリリークを報告します

Question

私が作成した大きなプロジェクトでvalgrindとAddressSanitizerを実行しましたが、私が使用する多くのマップでメモリリークが報告されます。しかし、私はプログラム内で動的メモリ割り当てを使用していません（new()への呼び出しは行われず、スマートポインタでさえもポインタは使用されません）。

残念ながら、元のコードは大きすぎて機密性条項の下にありますので、ここで完全に共有することはできません。私は最小限の複製を作成しようとしましたが、成功しませんでした。

基本的に私のコードベースの周りの多くのマップが漏れていると思われます。

は、私がそのエントリは、前のマップ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の内部ではありません）。特に、2つの異なるツールで報告されているように、私は本当に "リーク"を説明できません。 （特定の）マップだけが漏れているので、私はコードの周りにsetと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<には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; 
    } 
}; 

比較演算子は、マップは、に動作を反復、厳しい弱い順序付けを提供していません。予期しない方法（たとえば、がstd::distance(map.begin(), map.end())より大きいとマップに報告できます）。私の前提は、マップのデストラクタは、誤った比較の実装のために、削除のために内部要素すべてにアクセスすることができないということです。