gSOAP C++ client memory leak

Question

I have read the gSOAP docs and seen mentions of the fact that one should call soap_destroy(soap) and soap_end(soap) etc., however they are always examples with a single invocation on the service object. The service I am using returns about 40KB of text with each invocation. My problem is that memory usage grows linearly by about the same size for every request. I added soap_destroy(service->soap) within getWords to no avail. Can anyone indicate what cleanup code is missing from this code snippet? The requesting program should be running for days on end, so per request cleanup is what I am worried about rather than at shutdown.

I have posted below an analagous example (sans error checking) based on http://www.webservicex.net/WCF/ServiceDetails.aspx?SID=43, (it returns chunks of text right?). Any help is greatly appreciated!

#include "soapBibleWebserviceSoapProxy.h"
#include "BibleWebserviceSoap.nsmap"
#include <iostream>
extern "C" {
#include <unistd.h>
}

struct Service
{
    BibleWebserviceSoap service;

    std::string getWords(std::string &title, int chapter)
    {   
        _ns1__GetBibleWordsByBookTitleAndChapter req;
        _ns1__GetBibleWordsByBookTitleAndChapterResponse resp;
        req.BookTitle = &title;
        req.chapter   = 1;

        service.__ns2__GetBibleWordsByBookTitleAndChapter(&req, &resp);

        return *(resp.GetBibleWordsByBookTitleAndChapterResult);
    }
};

int main(int argc, char* argv[])
{
    Service s;
    std::string genesis("Genesis");
    for (int i=0; i<360; ++i)
    {   
        sleep(2);
        std::cout << s.getWords(genesis,1) << std::endl;
    }
    return 0;
}

Answer 1

Run your application under Valgrind (valgrind.org - usually installed by default on Linux) - it's the easiest way of tracking down memory leaks.

Do 1,000+ calls and on shutdown you'll see the leak. If the leak is not shown on shutdown, then some list or map collects entries but only releases them on shutdown - in this case use Massif (part of Valgrind) - it is also a great tool.

It's not a direct answer, but a stack trace of the allocation that eats memory usually helps a lot in pin-pointing a reason of a leak.