2017-11-14 3 views
2

Valgrind erkennt einige Speicherverluste in Gsoap. Dies ist ein sehr einfaches Beispiel Code:Valgrind meldet Speicherverlust in 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; 
} 

diesen Code zu kompilieren, verwende ich diese:

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

Und das sind die Speicherlecks durch Valgrind berichtet:

==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) 

Was ist Ich mache falsch? Fehle ich eine Anweisung? Ich habe gsoap Dokumentation und Internet gelesen, aber ich habe nichts gefunden.

Vielen Dank!

+0

Ich bin nicht vertraut mit gSoap, aber ist das wirklich, wie es in C++ funktionieren soll? Ich sehe hier https://github.com/stoneyrh/gSOAP/blob/master/gsoap/stdsoap2.cpp, dass es einen Destruktor gibt, der zerstört/end/done aufruft. –

+0

Hallo Paul, ich habe einen Blick darauf geworfen und der Aufruf von soap_done kann entfernt werden. Aber Valgrind meldet immer noch die gleichen Speicherverluste – hebrerillo

+0

Es sieht so aus, als ob die Bibliothek initialisiert bleibt. Gibt es einen Grund, warum das ein Problem ist? Möchten Sie, dass es sich jedes Mal initialisiert, wenn Sie ein Objekt erstellt haben? –

Antwort

1

Kompilieren Sie Ihren Code mit -DDEBUG nicht, um mit Valgrind zu testen, weil es den internen Speicherlecküberprüfer von gSOAP aktiviert. Dies kann mit Valgrind interferieren.

EDIT:

ich überprüft diese mit der neuesten Version 2.8.61, die kein Leck im Debug-Modus zeigt oder auf andere Weise. Ich schlage vor, auf gSOAP 2.8.61 zu aktualisieren.

+0

Hallo danke für deine Antwort! Aber das ist keine Option. Meine Testgruppe beschwert sich, weil der Speicher zu schnell wächst, und das liegt an diesem gsoap-Code. – hebrerillo

+0

Ich verstehe, aber die Ausführung von 'soap_done()' entfernt zugewiesenen Speicher, wenn '-DDEBUG' verwendet wird, nicht früher. So haben 'soap_destroy()' und 'soap_end()' einen begrenzten Effekt. Der Grund dafür ist einfach: Es hilft, Probleme zu erkennen, wenn Daten dereferenziert werden, die in Ihrem Code oder von der Engine freigegeben wurden. Sei besser als Nachsicht. Sie sollten '-DDEBUG' nicht im Produktionscode verwenden. –

+0

Hallo Dr. Alex RE, nochmals vielen Dank für Ihre Antwort, aber nach dem Lesen Ihres Kommentars konnte ich nicht verstehen, warum Gsoap Speicherlecks in Debug-Umgebung hat (ich verwende nicht -DDEBUG in der Produktionsumgebung). – hebrerillo

Verwandte Themen