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