Re: Memory leak in ICAPXaction

> Hi Amos,
>
> Amos Jeffries wrote:
>> Further to the major memory leaks found by Steinar H. Gunderson ....
>>
>> This is also popping out, and very confusing since ICAPXaction global is
>> only created once right?
>
> it is the "new PconnPool" line. It is create only once. It says its
> reachable because the time of shutdown the icapPconnPool points on it.

... which is preventing memPools deallocating any of it...

> Should not be a problem...

Aye, the code _looks right_ but there is something fishy going on.
Unless I'm fully mistaken on what a block is, a single call to xmalloc
should not be generating: "155,949 blocks" in case #12, or again a single
call to xcalloc generating "3,122 blocks" for case #2.

>
>>
>>
>> ==23075==
>> ==23075== 16,245,636 bytes in 155,949 blocks are still reachable in loss
>> record 29 of 30
>> ==23075== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
>> ==23075== by 0x5C4F07: xmalloc (util.c:506)
>> ==23075== by 0x5A591D: _GLOBAL__I_ICAPXaction.cc (SquidNew.h:48)
>> ==23075== by 0x5C9155: (within /usr/sbin/squid3)
>> ==23075== by 0x47E9AA: (within /usr/sbin/squid3)
>> ==23075==
>> ==23075==
>> ==23075== 44,001,178 bytes in 3,122 blocks are still reachable in loss
>> record 30 of 30
>
> Are the 44Mbytes normal for a PconnPool object?

I hope not. It's meant to be a simple hash of currently active persistent
connections.

>
>> ==23075== at 0x4C203E4: calloc (vg_replace_malloc.c:397)
>> ==23075== by 0x5C4DF1: xcalloc (util.c:688)
>> ==23075== by 0x5BFB0F: hash_create (hash.c:147)
>> ==23075== by 0x52D809: PconnPool::PconnPool(char const*)
>> (pconn.cc:236)
>> ==23075== by 0x5A592F: _GLOBAL__I_ICAPXaction.cc (ICAPXaction.cc:15)
>> ==23075== by 0x5C9155: (within /usr/sbin/squid3)
>> ==23075== by 0x47E9AA: (within /usr/sbin/squid3)
>>
>>
>> Amos
>
>
Received on Thu Feb 12 2009 - 01:06:50 MST