Re: memory leak associated w/running any ecap adapter

On 12/30/2012 03:36 PM, carteriii wrote:
> 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 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

This particular memory is "leaked" only once per Squid lifetime or, in
the worst case, per [re]configure, so it is not the leak you are looking
for.

All other leak records in the updated valgrind1000-callers-50.out file
are also benign. They all stem from configuration file parsing and
similar initialization routines, not runtime code.

Interestingly enough, valgrind1-callers-50.out does show what could be a
runtime leak. Please see if the attached patch fixes the eCAP sample
adapters. If it helps, please let us know. If it does not help, please
update the results (Squid and valgrind logs) again after applying the patch.

If you do more tests, if you can, please suppress valgrind leak reports
originating from mainInitialize() and parseConfigFile(). You are not
interested in those and they create a lot of noise in the valgrind report.

Thank you,

Alex.