Re: memory leak associated w/running any ecap adapter

On 12/30/2012 10:09 AM, carteriii wrote:

> As an extra step, I then re-ran the test sending in one-thousand (1000)
> requests for the same simple html file. I wanted to see which potential
> memory loss grew the most, thinking that might help identify the specific
> cause of this problem. I captured the valgrind heap output and have
> included that as well. The largest potential loss from my run of 1,000 is:
>
> ==9921== 210,120 bytes in 51 blocks are possibly lost in loss record 1,254
> of 1,267
> ==9921== at 0x402A5E6: calloc (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==9921== by 0x83B0905: xcalloc (xalloc.cc:75)
> ==9921== by 0x83AB493: MemPoolMalloc::allocate() (MemPoolMalloc.cc:62)
> ==9921== by 0x83A8FF0: MemImplementingAllocator::alloc() (MemPool.cc:242)
> ==9921== by 0x83A93B6: MemAllocatorProxy::alloc() (MemPool.cc:355)
> ==9921== by 0x824E958: mem_node::operator new(unsigned int) (in
> /usr/local/squid3/sbin/squid)
> ==9921== by 0x824DF90: mem_hdr::nodeToRecieve(long long) (stmem.cc:335)
> ==9921== by 0x824E498: mem_hdr::write(StoreIOBuffer const&)
> (stmem.cc:385)
> ==9921== by 0x8220FCD: MemObject::write(StoreIOBuffer, void (*)(void*,
> StoreIOBuffer), void*) (MemObject.cc:163)
> ==9921== by 0x8252188: StoreEntry::write(StoreIOBuffer) (store.cc:878)
> ==9921== by 0x82522BC: StoreEntry::append(char const*, int)
> (store.cc:897)
> ==9921== by 0x8252373: storeAppendVPrintf(StoreEntry*, char const*,
> char*) (store.cc:918)

> 10k requests (10x more than this test of 1k requests) with this sample file
> leaks about 200MB according to top, so this appears to me to be the culprit.

Do you get the same kind of "possibly lost" valgrind record when running
the same test with eCAP disabled? If not, do you at least get the smake
kind of memory growth?

Thank you,

Alex.
Received on Sun Dec 30 2012 - 21:40:39 MST