Re: memory leak associated w/running any ecap adapter

I just re-ran the tests with valgrind --num-callers=50. I re-uploaded the
same .tar.gz file with these new outputs. By file name they are:

valgrind-no-ecap.out - 1k tests without ecap on or module loaded
valgrind1-callers-50.out - original single call test but with deeper stack
valgrind1000-callers-50.out - original 1k call (w/ecap & passthru) with
deeper stack

That last entry with the deeper stack is pasted below:

==10724== 210,120 bytes in 51 blocks are possibly lost in loss record 1,295
of 1,308
==10724== at 0x402A5E6: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10724== by 0x83B0905: xcalloc (xalloc.cc:75)
==10724== by 0x83AB493: MemPoolMalloc::allocate() (MemPoolMalloc.cc:62)
==10724== by 0x83A8FF0: MemImplementingAllocator::alloc()
(MemPool.cc:242)
==10724== by 0x83A93B6: MemAllocatorProxy::alloc() (MemPool.cc:355)
==10724== by 0x824E958: mem_node::operator new(unsigned int) (in
/usr/local/squid3/sbin/squid)
==10724== by 0x824DF90: mem_hdr::nodeToRecieve(long long) (stmem.cc:335)
==10724== by 0x824E498: mem_hdr::write(StoreIOBuffer const&)
(stmem.cc:385)
==10724== by 0x8220FCD: MemObject::write(StoreIOBuffer, void (*)(void*,
StoreIOBuffer), void*) (MemObject.cc:163)
==10724== by 0x8252188: StoreEntry::write(StoreIOBuffer) (store.cc:878)
==10724== by 0x82522BC: StoreEntry::append(char const*, int)
(store.cc:897)
==10724== by 0x8252373: storeAppendVPrintf(StoreEntry*, char const*,
char*) (store.cc:918)
==10724== by 0x822C121: packerPrintf (Packer.cc:178)
==10724== by 0x81F38E1: httpStatusLinePackInto (HttpStatusLine.cc:93)
==10724== by 0x8208946: HttpReply::packHeadersInto(Packer*) const
(HttpReply.cc:134)
==10724== by 0x8256AAE: StoreEntry::startWriting() (store.cc:1857)
==10724== by 0x82569EB: StoreEntry::replaceHttpReply(HttpReply*, bool)
(store.cc:1837)
==10724== by 0x8223F39: MimeIcon::created(StoreEntry*) (mime.cc:472)
==10724== by 0x82513F7: StoreEntry::getPublic(StoreClient*, char const*,
HttpRequestMethod const&) (store.cc:614)
==10724== by 0x8223A84: MimeIcon::load() (mime.cc:408)
==10724== by 0x8223812: mimeInit (mime.cc:377)
==10724== by 0x821ACC7: mainInitialize() (main.cc:1068)
==10724== by 0x821B752: SquidMain(int, char**) (main.cc:1460)
==10724== by 0x821AF84: SquidMainSafe(int, char**) (main.cc:1216)
==10724== by 0x821AF69: main (main.cc:1208)
==10724==
==10724== LEAK SUMMARY:
==10724== definitely lost: 116 bytes in 4 blocks
==10724== indirectly lost: 368 bytes in 21 blocks
==10724== possibly lost: 302,251 bytes in 1,825 blocks
==10724== still reachable: 14,875,252 bytes in 140,614 blocks
==10724== suppressed: 0 bytes in 0 blocks

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