2017-11-14 7 views
2

ValgrindはGsoapのメモリリークを検出しています。これは非常に基本的なサンプルコードです:valgrindはgsoapのメモリリークを報告します

//file hr.cpp 
#include "soapH.h" 
#include "ns1.nsmap" 

int main() 
{ 
    struct soap *soap_ = soap_new(); 

    soap_destroy(soap_); 
    soap_end(soap_); 
    //soap_done(soap_); 
    soap_free(soap_); 

    return 0; 
} 

このコードをコンパイルするには、私はこれを使用します。

g++ -D DEBUG -g -std=c++0x -o hr hr.cpp soapC.cpp stdsoap2.cpp 

そして、これらは、Valgrindので報告されたメモリリークです:

==5290== HEAP SUMMARY: 
==5290==  in use at exit: 72,800 bytes in 4 blocks 
==5290== total heap usage: 18 allocs, 14 frees, 244,486 bytes allocated 
==5290== 
==5290== 32 bytes in 1 blocks are definitely lost in loss record 1 of 4 
==5290== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==5290== by 0x41D6FF: soap_track_malloc (stdsoap2.cpp:8952) 
==5290== by 0x421347: soap_set_logfile (stdsoap2.cpp:10022) 
==5290== by 0x421402: soap_set_test_logfile (stdsoap2.cpp:10062) 
==5290== by 0x422391: soap_init_REQUIRE_lib_v20851 (stdsoap2.cpp:10405) 
==5290== by 0x43DD31: soap::soap() (stdsoap2.cpp:20074) 
==5290== by 0x41AF2E: soap_new_REQUIRE_lib_v20851 (stdsoap2.cpp:8109) 
==5290== by 0x40238C: main (hr.cpp:6) 
==5290== 
==5290== 32 bytes in 1 blocks are definitely lost in loss record 2 of 4 
==5290== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==5290== by 0x41D6FF: soap_track_malloc (stdsoap2.cpp:8952) 
==5290== by 0x421347: soap_set_logfile (stdsoap2.cpp:10022) 
==5290== by 0x4213DA: soap_set_sent_logfile (stdsoap2.cpp:10050) 
==5290== by 0x4223A2: soap_init_REQUIRE_lib_v20851 (stdsoap2.cpp:10406) 
==5290== by 0x43DD31: soap::soap() (stdsoap2.cpp:20074) 
==5290== by 0x41AF2E: soap_new_REQUIRE_lib_v20851 (stdsoap2.cpp:8109) 
==5290== by 0x40238C: main (hr.cpp:6) 
==5290== 
==5290== 32 bytes in 1 blocks are definitely lost in loss record 3 of 4 
==5290== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==5290== by 0x41D6FF: soap_track_malloc (stdsoap2.cpp:8952) 
==5290== by 0x421347: soap_set_logfile (stdsoap2.cpp:10022) 
==5290== by 0x4213B2: soap_set_recv_logfile (stdsoap2.cpp:10038) 
==5290== by 0x4223B3: soap_init_REQUIRE_lib_v20851 (stdsoap2.cpp:10407) 
==5290== by 0x43DD31: soap::soap() (stdsoap2.cpp:20074) 
==5290== by 0x41AF2E: soap_new_REQUIRE_lib_v20851 (stdsoap2.cpp:8109) 
==5290== by 0x40238C: main (hr.cpp:6) 
==5290== 
==5290== LEAK SUMMARY: 
==5290== definitely lost: 96 bytes in 3 blocks 
==5290== indirectly lost: 0 bytes in 0 blocks 
==5290==  possibly lost: 0 bytes in 0 blocks 
==5290== still reachable: 72,704 bytes in 1 blocks 
==5290==   suppressed: 0 bytes in 0 blocks 
==5290== Reachable blocks (those to which a pointer was found) are not shown. 
==5290== To see them, rerun with: --leak-check=full --show-leak-kinds=all 
==5290== 
==5290== For counts of detected and suppressed errors, rerun with: -v 
==5290== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) 

何午前私は間違っている? 指示がありませんか?私はgsoapのドキュメントとインターネットを通して読んだことがありますが、何も見つかりませんでした。

ありがとうございます!

+0

私はgSoapに慣れていませんが、これは実際にC++で動作するはずです。ここではhttps://github.com/stoneyrh/gSOAP/blob/master/gsoap/stdsoap2.cppにdestroy/end/doneを呼び出すデストラクタがあることがわかります。 –

+0

こんにちはポール、私は見て、soap_doneの呼び出しを削除することができます。しかしValgrindはまだ同じメモリリークを報告しています – hebrerillo

+0

ライブラリは初期化されたままです。何らかの理由で問題がありますか?オブジェクトを作成するたびに初期化されることをお勧めしますか? –

答えて

1

-DDEBUGを使用してコードをコンパイルしないでください。これは、gSOAPの内部メモリリークチェッカーを起動するため、valgrindでテストするためです。これはバングラドを妨げる可能性があります。

EDIT:

私は、DEBUGモードまたはそれ以外には、リークを示していない最新のリリース2.8.61でこれを確認しました。 gSOAP 2.8.61にアップグレードすることをお勧めします。

+0

ご回答いただきありがとうございます。しかし、それはオプションではありません。私のテストグループは、メモリーが高速になっているので不平を言っています。これは、このgsoapコードのためです。 – hebrerillo

+0

私は理解しますが、 'soap_done()'を実行すると、 '-DDEBUG'が使用されたときに割り当てられたメモリが削除されます。したがって、 'soap_destroy()'と 'soap_end()'は効果が制限されています。この理由は簡単です。データが参照解除されたときにコード内またはエンジンによって割り当てが解除されたときに問題を検出するのに役立ちます。申し訳ありませんよりも安全です。プロダクションコードで '-DDEBUG'を使うべきではありません。 –

+0

Dr. Alex REさん、あなたの回答をもう一度感謝します。しかし、あなたのコメントを読んだ後、gsoapがデバッグ環境でメモリリークを起こす理由を理解できませんでした(私は実稼働環境で-DDEBUGを使用していません)。 – hebrerillo

関連する問題