memory leak of ecap modules

Asked by qianguozheng on 2016-06-15

Hi Guys:

I encounter with the Squid memory usage grow constantly, but when I disable the ecap module the memory just stop increasing, so I infer that the ecap module may have memory leak ?

But, while I come through the whole code, just found that I use the get request url with pointer and client in pointer, but I don't see any memory leak problem.

 "clientIP" need free ? or requestLine need free ? or uri need free ?

1. Get the client ip address.
libecap::Header::Value clientIP = hostx->option(libecap::metaClientIp);

2. get the request url.

typedef libecap::RequestLine *CLRLP;
CLRLP requestLine;
libecap::Area uri;

 if (requestLine = dynamic_cast<CLRLP>(&hostx->virgin().firstLine())) {
            uri = requestLine->uri();
    } else {
        if (requestLine = CLRLP(&hostx->cause().firstLine()))
                uri = requestLine->uri();
    }

Or, can you provide me some method to detect where could be the memory leak happened ?

Thanks in advance.

Question information

Language:
English Edit question
Status:
Solved
For:
eCAP Edit question
Assignee:
No assignee Edit question
Solved by:
qianguozheng
Solved:
2016-06-16
Last query:
2016-06-16
Last reply:
2016-06-15

My ecap module based on http://www.measurement-factory.com/tmp/ecap/ecap_adapter_sample-1.0.0.tar.gz
using the adapter_modifying.cc module, now I just add get clientip and request url function, to adapt content which not compressed.

But it still has the memory continue increasing problem.

I observe that the Xaction object often not call the destructor function look at the log printed by "this" pointer, it often stop at
function Adapter::Xaction::abContent(size_type offset, size_type size)
after that, will be the Adapter::Service::wantsUrl(const char *url) API call by other thread.

Could it be the problem that squid not free Xaction object ? why it didn't free it ?

Fixed on this link.
http://squid-web-proxy-cache.1019090.n4.nabble.com/memory-leak-associated-w-running-any-ecap-adapter-td4657812.html

But, I still want to know whether below parameters need released ?

 "clientIP" need free ? or requestLine need free ? or uri need free ?

1. Get the client ip address.
libecap::Header::Value clientIP = hostx->option(libecap::metaClientIp);

2. get the request url.

typedef libecap::RequestLine *CLRLP;
CLRLP requestLine;
libecap::Area uri;

 if (requestLine = dynamic_cast<CLRLP>(&hostx->virgin().firstLine())) {
            uri = requestLine->uri();
    } else {
        if (requestLine = CLRLP(&hostx->cause().firstLine()))
                uri = requestLine->uri();
    }

Fixed on this link.
http://squid-web-proxy-cache.1019090.n4.nabble.com/memory-leak-associated-w-running-any-ecap-adapter-td4657812.html

But, I still want to know whether below parameters need released ?

 "clientIP" need free ? or requestLine need free ? or uri need free ?

1. Get the client ip address.
libecap::Header::Value clientIP = hostx->option(libecap::metaClientIp);

2. get the request url.

typedef libecap::RequestLine *CLRLP;
CLRLP requestLine;
libecap::Area uri;

 if (requestLine = dynamic_cast<CLRLP>(&hostx->virgin().firstLine())) {
            uri = requestLine->uri();
    } else {
        if (requestLine = CLRLP(&hostx->cause().firstLine()))
                uri = requestLine->uri();
    }

Alex Rousskov (rousskov) said : #5

> Fixed on this link.

Actually, it was fixed here: http://www.squid-cache.org/mail-archive/squid-dev/201212/0239.html

The nabble thread you found was mostly invisible to the Squid Project mailing list.

The fix is included in sample v1.0 which you should be using with modern eCAP hosts, including Squid.

> But, I still want to know whether below parameters need released?

No, they are either not pointers or they are smart pointers that free memory automatically.

> can you provide me some method to detect where could be the memory leak happened ?

This is a general development question, not an eCAP-specific question. Running the host application under valgrind or a similar tool is often a useful step towards leak detection (and fixing). Unfortunately, correctly interpreting valgrind results is usually not trivial, especially in complex and unpolished hosts like Squid.

Thanks alex, that fix my problem.