0

最近ブーストを使い始めましたが、提供されている機能と API に感銘を受けています。

boost::shared_ptr を使用して、Valgrind でプログラムを確認すると、かなりの数の「まだ到達可能」なメモリ リークが見つかりました。Valgrind のドキュメントによると、これらは問題ではありません。ただし、以前は標準の C++ ライブラリしか使用していなかったので、作成するプログラムがメモリ リークから完全に解放されていることを常に確認していました。

私の質問は、これらのメモリ リークは心配すべきことですか? reset() を使用してみましたが、参照カウントを減らすだけで、メモリの割り当てを解除しません。これらを安全に無視できますか、またはboost::shared_ptrによって割り当てられたメモリを強制的に解放する方法はありますか?

ありがとうございました。

EDIT1：

このコードでは apache thrift を使用しています。オプション --show-reachable=yes を使用して valigrind でさらに確認すると、ほとんどすべてのリーク メッセージは以下のようになります。

==6813== 24 bytes in 1 blocks are still reachable in loss record 3 of 21
==6813==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6813==    by 0x5E7A783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5EF524A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5E7BC17: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5E7C268: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5BF43C5: SSL_CTX_free (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==6813==    by 0x4E9574F: apache::thrift::transport::SSLContext::~SSLContext() (TSSLSocket.cpp:71)
==6813==    by 0x4E95768: apache::thrift::transport::SSLContext::~SSLContext() (TSSLSocket.cpp:74)
==6813==    by 0x4E96C08:  apache::thrift::transport::TSSLSocketFactory::~TSSLSocketFactory() (sp_counted_base_gcc_x86.hpp:145)
==6813==    by 0x4E96C98: apache::thrift::transport::TSSLSocketFactory::~TSSLSocketFactory() (TSSLSocket.cpp:369)
==6813==    by 0x42A986: void boost::checked_delete<apache::thrift::transport::TSSLSocketFactory>(apache::thrift::transport::TSSLSocketFactory*) (checked_delete.hpp:34)
==6813==    by 0x42ADE3: boost::detail::sp_counted_impl_p<apache::thrift::transport::TSSLSocketFactory>::dispose() (sp_counted_impl.hpp:78)

これは、メモリ リークを起こしているのはリサイクル コードであることを意味しますか?

ありがとう。

4

2 に答える 2

2

http://www.gnu.org/software/libc/manual/html_node/Statistics-of-Malloc.html#Statistics-of-Mallocをご覧ください。

uordblksプログラムの開始時と終了時が同じであれば、リークはありません。割り当てたメモリをすべて解放できたからです。

于 2012-10-29T17:59:53.397 に答える
2

通常、メモリがまだ到達可能な場合、それはリークではありません。次のように、malloc/new を使用して予約したメモリとしてリークを定義したが、それ以上解放できない場合

//this leaks since p is unreachable outside the scope
int main() {
  char * p = (char*)malloc(10);
  return 0; 
}

メモリが常に増加する状況が発生する可能性がありますが、技術的にはリークではありません。たとえば、常に何かを入れるグローバル リストがあり、それらを決して出さない場合などです。その場合、リスト メモリは到達可能であり、could解放します。

そうは言っても、質問に貼り付けられたコールスタックによって、参照されるメモリは、thrift SSLトランスポートを破棄するときにlibcryptoによって行われた割り当てのようです。

したがって、共有ポインタは問題ではありません。ほとんどの場合、libcrypto 内で使用されるバッファリングされたメモリです。

于 2012-10-29T18:30:15.787 に答える