3

Valgrind は以下を出力しています。

==14446== 2,976 (176 direct, 2,800 indirect) bytes in 2 blocks are definitely lost in loss record 23 of 33
==14446==    at 0x4C2506C: operator new(unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==14446==    by 0x41C487: __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::allocate(unsigned long, void const*) (new_allocator.h:92)
==14446==    by 0x41C4AB: std::_Rb_tree<unsigned, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn>, std::_Select1st<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::_M_get_node() (stl_tree.h:357)
==14446==    by 0x41C915: std::_Rb_tree<unsigned, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn>, std::_Select1st<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::_M_create_node(std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> const&) (stl_tree.h:366)
==14446==    by 0x5036E9A: std::_Rb_tree<unsigned, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn>, std::_Select1st<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base const*, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> const&) (stl_tree.h:852)
==14446==    by 0x5037027: std::_Rb_tree<unsigned, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn>, std::_Select1st<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::_M_insert_unique(std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> const&) (stl_tree.h:1148)
==14446==    by 0x5037227: std::_Rb_tree<unsigned, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn>, std::_Select1st<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::_M_insert_unique_(std::_Rb_tree_const_iterator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> >, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> const&) (stl_tree.h:1188)
==14446==    by 0x50375CD: std::map<unsigned, vimrid::imaging::ImageMatrixColumn, std::less<unsigned>, std::allocator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::insert(std::_Rb_tree_iterator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> >, std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> const&) (stl_map.h:496)
==14446==    by 0x50376DE: std::map<unsigned, vimrid::imaging::ImageMatrixColumn, std::less<unsigned>, std::allocator<std::pair<unsigned const, vimrid::imaging::ImageMatrixColumn> > >::operator[](unsigned const&) (stl_map.h:419)
==14446==    by 0x5036A43: vimrid::imaging::ImageMatrixRow::operator[](unsigned) (ImageMatrixRow.cpp:10)
==14446==    by 0x5034BBB: vimrid::imaging::ImageMatrix::_getRotatedCopy(double, vimrid::imaging::ImageMatrix&) (ImageMatrix.cpp:151)
==14446==    by 0x503350A: vimrid::imaging::processing::ImageFilter& vimrid::imaging::ImageMatrix::GetRotatedCopy<vimrid::imaging::processing::ImageFilter>(double) (ImageMatrix.h:48)

これは何を意味するのでしょうか？

//ImageMatrixRow.cpp:8-11
ImageMatrixColumn &ImageMatrixRow::operator[](VUInt32 columnIndex)
{
    return columns[columnIndex];
}

//ImageMatrix.cpp:151
target[x][y][0] = source[roundX][roundY][0];

//ImageMatrix.h:48
return *(T*)&_getRotatedCopy(degrees, CopyDimensions());
4

2 に答える 2

5

おそらくプールアロケーターが原因です。Valgrind FAQ から:

私のプログラムでは、C++ STL と文字列クラスを使用しています。Valgrind は、プログラムの終了時にこれらのクラスに関連する「まだ到達可能な」メモリ リークを報告しますが、何もないはずです。

まず第一に、リラックスしてください。これはおそらくバグではなく、機能です。C++ 標準ライブラリの多くの実装では、独自のメモリ プール アロケータが使用されています。かなりの数の破壊されたオブジェクトのメモリは、すぐに解放されて OS に戻されませんが、後で再利用するためにプールに保持されます。プログラムの exit() でプールが解放されないという事実により、Valgrind はこのメモリがまだ到達可能であると報告します。ただし、exit() でプールを解放しない動作は、ライブラリのバグと呼ぶことができます。

詳細については、 Valgrind FAQをご覧ください。

私は急いでいて、あなたのコードを分析できないので、間違っているかもしれません。

于 2009-04-19T21:10:57.283 に答える
1

エラーはコードからではなく、使用しているライブラリから発生しているようです。

Valgrind にはいくつかのデフォルトのエラー抑制が付属していますが、使用しているライブラリはおそらくカバーされていません。

エラー チェック ツールは、GNU C ライブラリや、GNU/Linux システムにプリインストールされている X11 クライアント ライブラリなどの基本ライブラリの多数の問題を検出します。これらを簡単に修正することはできませんが、これらのエラーを見たくはありません (もちろん、たくさんあります!)。そのため、Valgrind は起動時に抑制するエラーのリストを読み取ります。デフォルトの抑制ファイルは、システムの構築時に ./configure スクリプトによって作成されます。

コードとは無関係であることがわかっている独自のエラー抑制を作成できます。

同様の SO の質問を参照してください。

于 2009-04-20T02:59:01.037 に答える