valgrind reports memory leak in gsoap

Question

Valgrind is detecting some memory leaks in Gsoap. This is a very basic example code:

//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;
}

To compile this code, I use this :

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

And these are the memory leaks reported by 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)

What am I doing wrong? Am I missing any instruction? I have read through gsoap documentation and internet but I did not found anything.

Thanks a lot!

I'm not familiar with gSoap but is this really how it is supposed to work in C++? I see here https://github.com/stoneyrh/gSOAP/blob/master/gsoap/stdsoap2.cpp that there is a destructor that calls destroy/end/done. — Paul Floyd, Nov 14 '17 at 14:06
Hi Paul, I took a look and the call to soap_done can be removed. But Valgrind still reportes the same memory leaks — hebrerillo, Nov 15 '17 at 09:14
It looks like the library stays initialized. Is there some reason that's a problem? Would you prefer it initialized itself each time you created an object? — David Schwartz, Nov 15 '17 at 09:19

Dr. Alex RE · Answer 1 · 2018-02-05T18:06:16.290

1

Do not compile your code with -DDEBUG to test with valgrind, because it activates gSOAP's internal memory leak checker. This may interfere with valgrind.

EDIT:

I verified this with the latest release 2.8.61 which shows no leak in DEBUG mode or otherwise. I suggest to upgrade to gSOAP 2.8.61.

edited Feb 05 '18 at 18:06

answered Nov 15 '17 at 17:11

Dr. Alex RE

1,772
1
15
23

Hi thanks for your response! But that's not an option. My testing group is complaining because the memory is growing to fast, and that's because this gsoap code. – hebrerillo Nov 24 '17 at 10:06
I understand, but executing `soap_done()` removes allocated memory when `-DDEBUG` is used, not earlier. So `soap_destroy()` and `soap_end()` have limited effect. The reason for this is simple: it helps to detect problems when data is dereferenced that was deallocated in your code or by the engine. Better be safe than sorry. You should not use `-DDEBUG` in production code. – Dr. Alex RE Nov 27 '17 at 14:16
Hi Dr. Alex RE, thanks again for your response, but after reading your comment I failed to understand why gsoap has memory leaks in debug environment (I am not using -DDEBUG in production environment). – hebrerillo Dec 02 '17 at 11:47
Perhaps you are using an old version? Try a newer gSOAP release. From the `soap_track_malloc` I can tell that your code is compiled with `-DDEBUG`. Running this example on my end does not show a leak. – Dr. Alex RE Dec 06 '17 at 14:47

valgrind reports memory leak in gsoap

1 Answers1