[squid-users] Memory Leak Squid 3.4.9 on FreeBSD 10.0 x64

[Amos Jeffries]

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

On 13/01/2015 1:15 a.m., Yuri Voinov wrote:
> 
> Yep.
> 
> Memory leaking - if it really it - will be occurs on all
> platforms.
> 
> If not - this is OS-specific issue. libc, malloc library problem.
> But not squid itself.
> 

By definition a memory leak is memory which is "forgotten" /
dereference by the application (squid) without correctly calling
free/delete to release the memory back to the OS.

I am confident that those types of leaks do not exist at al in Squid 3.4.

These rounds of mmory exhaustion problems are caused by pseudo-leaks,
where Squid incorrectly holds onto memory (has not forgotten it
though) far longer than it should be.

> 
> 12.01.2015 18:06, Eugene M. Zheganin пишет:
>> Hi.
> 
>> On 12.01.2015 16:41, Eugene M. Zheganin wrote:
>>> I'm now also having a strong impression that squid is leaking
>>> memory. Now, when 3.4.x is able to handle hundreds of users
>>> during several hours I notice that it's memory usage is
>>> constantly increasing. My patience always ends at the point of
>>> 1.5 Gigs memory usage, where server memory starts to be
>>> exhausted (squid is running with lots of other stuff) and I
>>> restart it. This is happening on exactly the same config the
>>> 3.3.13 was running, so ... I have cache_mem set to 512 megs,
>>> diskd, medium sized cache_dir and lots of users. Is something 
>>> changed drastically in 3.4.x comparing to the 3.3.13, or is it,
>>> as it seems, a memory leak ?
>> Squid 3.4 on FreeBSD is by default compiling with the 
>> --enable-debug-cbdata option and when 45th log selector is at
>> it's default 1, cache.log is filling with CBData memory leaking
>> alarms. Here is the list for the last 40 minutes, sorted with the
>> occurrence count:
> 
>> 104136 Checklist.cc:160 81438 Checklist.cc:187 177226
>> Checklist.cc:320 84861 Checklist.cc:45 89151 CommCalls.cc:21 
>> 22069 DiskIO/DiskDaemon/DiskdIOStrategy.cc:353 120
>> UserRequest.cc:166 29 UserRequest.cc:172 55814
>> clientStream.cc:235 5966 client_side_reply.cc:93 4516
>> client_side_request.cc:134 5568 dns_internal.cc:1131 4859
>> dns_internal.cc:1140 86 event.cc:90 7770 external_acl.cc:1426 
>> 1548 fqdncache.cc:340 7467 helper.cc:856 39905 ipcache.cc:353 
>> 11880 store.cc:1611 181959 store_client.cc:154 256951
>> store_client.cc:337 6835 ufs/UFSStoreState.cc:333
> 
>> are those all false alarms ?

Those have been confirmed as false alerts. The C-style code releases
locks first while still holding a pointer (and logs the warning about
leak) then frees that pointer (outside the cbdata code) ... the C++
code does it the other way around with cbdata code doing free before
releasing the final lock.

I am back at the head-scratching stage about where those cbdata issues
are coming from.

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

iQEcBAEBAgAGBQJUs9TrAAoJELJo5wb/XPRjHMsIAL48yDQP91+DaX3F1ctY4uYw
hFMMiSL48rd/4KYvwXs+7Cy2HEzcF7mMQpkcY92MdX0PYtsTAIDnP5Cggm56knqB
aV4UtwgethI5qvcJlGRXrCpsmqEYjvC4w7PEdvEBRyzAZTv9g36hWMMc9IZtMX6R
Yqga9pnUPvIl1Cm1e/5eD/kPfxJm4KMdBrW1jRyhD9z515F+1rko5rD0wIGZBomn
KFi/ieb52JPa5+nZLKgn3q/8EQyvsVC56J0UeuZwPj1qrZE13fLAEawydxyv9/PJ
RbTaoYAOzcXTTwylOrTRntnwZr+qN5pSr7eUVYv+XdEoVHrII49RlwtB6qJrUfM=
=ychL
-----END PGP SIGNATURE-----