mongocxx :: instance inst {};でメモリリークが発生しました。

Question

Valgrindは私にstill reachableレコードをmongocxx :: instance inst {}で与えます。

==3014== 16,384 bytes in 1 blocks are still reachable in loss record 609 of 609 
==3014== at 0x5374C20: realloc (vg_replace_malloc.c:662) 
==3014== by 0x396046ACCE: CRYPTO_realloc (in /usr/lib64/libcrypto.so.1.0.1e) 
==3014== by 0x39604E604D: lh_insert (in /usr/lib64/libcrypto.so.1.0.1e) 
==3014== by 0x39604E87C8: ??? (in /usr/lib64/libcrypto.so.1.0.1e) 
==3014== by 0x39604E814B: ??? (in /usr/lib64/libcrypto.so.1.0.1e) 
==3014== by 0x396054C2FD: ERR_load_CMS_strings (in /usr/lib64/libcrypto.so.1.0.1e) 
==3014== by 0x3963045A38: SSL_load_error_strings (in /usr/lib64/libssl.so.1.0.1e) 
==3014== by 0x62BD653: ??? (in /usr/lib64/libmongoc-1.0.so.0.0.0) 
==3014== by 0x62A2278: ??? (in /usr/lib64/libmongoc-1.0.so.0.0.0) 
==3014== by 0x395BC0CE02: pthread_once (in /lib64/libpthread-2.12.so) 
==3014== by 0x55ADDE5: std::unique_ptr<mongocxx::v_noabi::instance::impl, std::default_delete<mongocxx::v_noabi::instance::impl> > core::v1::make_unique<mongocxx::v_noabi::instance::impl, void, std::unique_ptr<mongocxx::v_noabi::logger, std::default_delete<mongocxx::v_noabi::logger> > >(std::unique_ptr<mongocxx::v_noabi::logger, std::default_delete<mongocxx::v_noabi::logger> >&&) (in /usr/lib64/libmongocxx.so.3.0.3) 
==3014== by 0x55ADAEE: mongocxx::v_noabi::instance::instance(std::unique_ptr<mongocxx::v_noabi::logger, std::default_delete<mongocxx::v_noabi::logger> >) (in /usr/lib64/libmongocxx.so.3.0.3) 
==3014== by 0x55ADCF4: mongocxx::v_noabi::instance::instance() (in /usr/lib64/libmongocxx.so.3.0.3) 
==3014== by 0x4F6188: main (main.c:280) 

どうすればこの問題を解決できますか。 インスタンスをforkの後で宣言しますが、スレッドを作成する前に宣言します。

Answer 1

私の推薦は、あなたが次のことを確認した後、これに対する抑制を書くことになります：

• はあなたmongocxx::instanceオブジェクトのデストラクタが実行されていることを確認したことがありますか？
• そのオブジェクトのdtorが実際にmongoc_cleanupを呼び出していることを確認しましたか？

これらの両方が当てはまる場合は、libcryptoが実際に割り当てられたデータを任意のパスで解放するかどうかを確認することです。その答えが「はい」の場合、次の質問はなぜ呼び出されないのかを尋ねることです。その答えが "いいえ"ならば、あなたは抑制を書くべきです。

これはほぼ確実に1回限りの割り当てであり、無制限のメモリ増加につながる操作ごとのコンテキストに結びついていないため、ここでは抑制の記述が適切です。

さらに、メモリが実際にはリークされないことに注意してください。メモリはまだ到達可能です。