Re: [squid-users] Valgrind results on 3.2.1

On 27/09/2012 8:04 p.m., tcr_at_raynersw.com wrote:
> Here is what valgrind has printed out so far. Nothing major... only ~25KB identified by valgrind as leaks so far.

Thank you.

>
>
> ==26647== Memcheck, a memory error detector
> ==26647== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==26647== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
> ==26647== Command: squid -N -f /etc/squid/squid.conf
> ==26647==
> ==26647== Invalid read of size 8
> ==26647== at 0x6CE3D2D: __strspn_sse42 (in /lib64/libc-2.12.so)
> ==26647== by 0x535F79: strListGetItem (HttpHeaderTools.cc:259)

I have reported this as a bug to be fixed. We should not be depending on
strspn() with an unterminated buffer. But there is nothing we can do
about it until strListGetItem is redesigned.
   You can add an ignore rule to valgrind to hide these strspn() detections.

> ==26647== 96 bytes in 1 blocks are definitely lost in loss record 828 of 1,726
> ==26647== at 0x4C25A28: calloc (vg_replace_malloc.c:467)
> ==26647== by 0x65B441: xcalloc (xalloc.cc:75)
> ==26647== by 0x657B99: MemPoolMalloc::allocate() (MemPoolMalloc.cc:62)
> ==26647== by 0x5AA7C0: acl_ip_data::FactoryParse(char const*) (Ip.cc:436)
> ==26647== by 0x5AA8BD: ACLIP::parse() (Ip.cc:523)
> ==26647== by 0x5E0A80: ACL::ParseAclLine(ConfigParser&, ACL**) (Acl.cc:174)
> ==26647== by 0x4B0C0F: parse_line(char*) (cache_cf.cc:1252)
> ==26647== by 0x4B2076: parseOneConfigFile(char const*, unsigned int) (cache_cf.cc:518)
> ==26647== by 0x4B29D0: parseConfigFile(char const*) (cache_cf.cc:558)
> ==26647== by 0x546B81: SquidMain(int, char**) (main.cc:1372)
> ==26647== by 0x547445: main (main.cc:1215)
> ==26647==
>
> ==26647==
> ==26647== 384 bytes in 4 blocks are definitely lost in loss record 1,132 of 1,726
> ==26647== at 0x4C25A28: calloc (vg_replace_malloc.c:467)
> ==26647== by 0x65B441: xcalloc (xalloc.cc:75)
> ==26647== by 0x657B99: MemPoolMalloc::allocate() (MemPoolMalloc.cc:62)
> ==26647== by 0x5A95B1: acl_ip_data::FactoryParse(char const*) (Ip.h:66)
> ==26647== by 0x5AA8BD: ACLIP::parse() (Ip.cc:523)
> ==26647== by 0x5E0A80: ACL::ParseAclLine(ConfigParser&, ACL**) (Acl.cc:174)
> ==26647== by 0x4B0C0F: parse_line(char*) (cache_cf.cc:1252)
> ==26647== by 0x4B2076: parseOneConfigFile(char const*, unsigned int) (cache_cf.cc:518)
> ==26647== by 0x4B29D0: parseConfigFile(char const*) (cache_cf.cc:558)
> ==26647== by 0x546B81: SquidMain(int, char**) (main.cc:1372)
> ==26647== by 0x547445: main (main.cc:1215)

Fixed.

> ==26647==
> ==26647== 416 bytes in 26 blocks are definitely lost in loss record 1,142 of 1,726
> ==26647== at 0x4C26FDE: malloc (vg_replace_malloc.c:236)
> ==26647== by 0x65B3B7: xmalloc (xalloc.cc:116)
> ==26647== by 0x63B0FF: Comm::ConnOpener::connect() (SquidNew.h:47)
> ==26647== by 0x63B9F3: Comm::ConnOpener::start() (ConnOpener.cc:189)
> ==26647== by 0x5E4DA3: JobDialer<AsyncJob>::dial(AsyncCall&) (AsyncJobCalls.h:175)
> ==26647== by 0x5E29C2: AsyncCall::make() (AsyncCall.cc:36)
> ==26647== by 0x5E532A: AsyncCallQueue::fireNext() (AsyncCallQueue.cc:54)
> ==26647== by 0x5E54BF: AsyncCallQueue::fire() (AsyncCallQueue.cc:40)
> ==26647== by 0x4EF53B: EventLoop::runOnce() (EventLoop.cc:131)
> ==26647== by 0x4EF607: EventLoop::run() (EventLoop.cc:95)
> ==26647== by 0x546F87: SquidMain(int, char**) (main.cc:1500)
> ==26647== by 0x547445: main (main.cc:1215)

Can't seem to find this one (yet). Its not clear enough on which part of
connect() the leak is being done. There seem to be a few functions
inlined and potential candidates.

At 200res/sec I can imagine this being the source of a fair chunk of
leakage.

> ==26647== LEAK SUMMARY:
> ==26647== definitely lost: 896 bytes in 31 blocks
> ==26647== indirectly lost: 0 bytes in 0 blocks
> ==26647== possibly lost: 24,176 bytes in 200 blocks
> ==26647== still reachable: 325,406,108 bytes in 894,930 blocks
> ==26647== suppressed: 0 bytes in 0 blocks
> ==26647== Reachable blocks (those to which a pointer was found) are not shown.
> ==26647== To see them, rerun with: --leak-check=full --show-reachable=yes
>
>

Amos
Received on Thu Sep 27 2012 - 10:16:43 MDT