[squid-users] leaking memory in squid 3.4.8 and 3.4.7.

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/09/2014 10:04 p.m., Steve Hill wrote:
> On 28.09.14 08:34, Eliezer Croitoru wrote:
> 
>> Also to minimize the leak source try to share more information
>> about your usage. Are you using SMP workers or not? What is the
>> mem and info options in the cache manager page data? Did you
>> tried "cache deny all" acl to minimize the source of the leak?
> 
> For what its worth, I'm also seeing a big memory leak on multiple 
> servers under Squid 3.4.6:
> 
> I have two basic Squid configurations - one of them is a plain
> caching proxy and is _not_ leaking.  The other does no caching, but
> is doing ICAP, external ACLs, SSL bumping and TPROXY and leaks like
> a sieve (several gigabytes a day).
> 
> I _think_ I have narrowed it down to something ICAP related and
> I'm currently valgrinding.  Unfortunately I can't seem to get the
> valgrind instrumentation to work so I'm having to do without (I
> compile --with-valgrind-debug but "squidclient mgr:mem" doesn't
> produce a valgrind report).  I have noticed that there are a _lot_
> of memory errors reported by valgrind though (uninitialised
> memory).

IIRC the valgrind report is strangely at the end of mgr:info rather
than mgr:mem. It also only lists details if there is *real* leaked memory.

With one small exception all the reports of memory "leaks" in
3.2/3.3/3.4 series are in fact memory over-allocations. The difference
is that over-allocated memory is still referenced by some part of
Squid, so it *does not* show up in a leak finder like valgrind.

For example; most of Victors "leak" was in fact thousands of hung
asynchronous code chains/threads waiting for some network I/O which
could never happen, or if it does not for some very long time. Still
perfectly accessible to Squid via the index of active IDENT lookups
(ie not leaked), but should have been explicitly released already.



> 
> Pretty much all of the leaky memory is showing up as unaccounted: 
> Memory accounted for: Total accounted:        84306 KB   3% memPool
> accounted:      84306 KB   3% memPool unaccounted:   2917158 KB
> 97%
> 
> I am using SMP workers, but turning that off doesn't fix the
> issue.
> 

If you are using a 64-bit OS then the unaccounted numbers there are
bogus. They are based on mallinfo() lookup results which suffer from
32-bit wrap issues. Use the OS command line to get a memory report
from top or similar instead.

HTH
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUKrp/AAoJELJo5wb/XPRjfgEH/jMS0eZ0y/rZ4k4nZAprDCmr
+iJrBOR7/7yObQ4FEZlX793qofky760x35VuHvVantzl0oy2CNk2rCmluI85WOTn
i4WYfCvU/1J5ECp9PnodcslldgFM8TXcG5yuXhj2Ro36Prs0RYuXvwC7cuf4ASd9
BuoP/RCbNjlJFwHoHEcXM35OLMU0dshnSZ6YnesLOZODRUz9qNJK/x1Q0xeXAXBC
LjRatV2IEr8O5iV6BqTHQDVHOAUuG/m35dIeruyeg6r3pLngtR8PYxWfLsdTVxfP
UUjN4EoVozpyuIytvB4/PYSKDkFf8AtQbEnznXtnuyaWZR49/E8kpSp4bd61fyg=
=x7XO
-----END PGP SIGNATURE-----