memory leak associated w/running any ecap adapter

Enabling ecap with the sample adapters (e.g. adapter_passthru.cc,
adapter_modifying.cc) causes a significant memory leak. The leak is also
present with my own custom adapter, but I assume it is best to discuss this
is the context of the sample adapters.

A discussion was started about 3 months ago on the eCap list where another
user provided a lot of detailed information about the problem, including
running valgrind. That thread can be found through this URL:

https://answers.launchpad.net/ecap/+question/209483

The other user ran his tests with squid 3.2.1 and
squid-3.HEAD-20121018-r12399. I just ran a similar test with 3.2.5 showing
the same behavior. The other thread initially focused on
adapter_modifying.cc and later confirmed the memory leak with
adapter_passthru.cc. I have also just confirmed that all sample adapters
including adapter_passthru.cc display a memory leak. I see this behavior by
simply running:

> ab -n 1000 -c 2 http://

The memory growth appears somewhat linear with the number of test iterations
as simply measured by watching 'top'.

I won't repeat the entire other thread here, but I think this one section is
probably the most relevant:

***************************************************
I found one "definitely lost" record mentioning the adapter itself:

==29984== 8,207,949 (3,776 direct, 8,204,173 indirect) bytes in 118 blocks
are definitely lost in loss record 794 of 803
==29984== at 0x402BE68: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==29984== by 0x82ACE59: xmalloc (xalloc.cc:116)
==29984== by 0x81A644E: operator new(unsigned int) (SquidNew.h:47)
==29984== by 0x40387F3:
Adapter::Service::makeXaction(libecap::host::Xaction*)
(adapter_modifying.cc:188)
==29984== by 0x829D135:
Adaptation::Ecap::ServiceRep::makeXactLauncher(HttpMsg*, HttpRequest*)
(ServiceRep.cc:174)
==29984== by 0x828E162: Adaptation::Iterator::step() (Iterator.cc:73)
==29984== by 0x828F384: Adaptation::Iterator::start() (Iterator.cc:44)
==29984== by 0x820FBF3: NullaryMemFunT<AsyncJob>::doDial()
(AsyncJobCalls.h:101)
==29984== by 0x820FD45: JobDialer<AsyncJob>::dial(AsyncCall&)
(AsyncJobCalls.h:175)
==29984== by 0x820FEE1: AsyncCallT<NullaryMemFunT&lt;AsyncJob> >::fire()
(AsyncCall.h:142)

Squid seems to be losing the allocated Adapter transaction. It is difficult
to say whether the adapter lost it, but given all other losses in your log,
I am inclined to think that it was lost along with some Squid adaptation
structures that link to it.
***************************************************

My skills are not at the same level as most of you on this list, but I have
an environment in which I've compiled squid and the ecap adapters and I'll
do whatever I can. Will someone please give me some guidance to help fix
this memory leak? Since this happens with the standard ecap adapters, I
suspect anyone & everyone should be able to reproduce this pretty easily.
Please help me. Thank you.

Tom

--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/memory-leak-associated-w-running-any-ecap-adapter-tp4657812.html
Sent from the Squid - Development mailing list archive at Nabble.com.