Re: memory leak associated w/running any ecap adapter

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Sat, 29 Dec 2012 13:41:18 -0700

On 12/28/2012 01:22 PM, carteriii wrote:
> 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

...

> 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?

I suggest the following procedure as a starting point:

0. Stop Squid.

1. Empty cache.log.

2. Set debug_options to ALL,9. Set memory_pools to off. Set
memory_pools_limit to 0. Use adapter_passthru.

3. Start Squid.

4. Send a single request using "ab" or whatever tool you are using to
reproduce the leak.

5. Wait for the transaction to finish and all connections to close.

6. Copy cache.log somewhere (before you stop Squid).

7. Post compressed cache.log copy here, to Squid bugzilla, lp, or email
it to me privately.

Ideally, do the above with a Squid executable ./configured with
--disable-optimizations and --with-valgrind-debug and running under
valgrind control. If you do that, post valgrind log as well. Make sure
it shows the leak. If it does not, you may need to send more requests
through Squid (perhaps special requests or conditions are required for
the leak to occur).

Several iterations may be needed if we need to add debugging to pin
point the memory leak, but I hope it would not take too many.

HTH,

Alex.
Received on Sat Dec 29 2012 - 20:41:36 MST

This archive was generated by hypermail 2.2.0 : Sun Dec 30 2012 - 12:00:07 MST