(valgrind --tool=memcheck --leak-check=yes squid -Nd1) 2011/10/12 01:25:38| Asking valgrind for memleaks ==9877== 36 bytes in 1 blocks are definitely lost in loss record 606 of 1,292 ==9877== at 0x4026864: malloc (vg_replace_malloc.c:236) ==9877== by 0x407BFD5: cap_init (in /lib/libcap.so.2.20) ==9877== by 0x407C0FB: cap_get_proc (in /lib/libcap.so.2.20) ==9877== by 0x80C651B: restoreCapabilities (tools.c:1367) ==9877== by 0x80C72FA: leave_suid (tools.c:644) ==9877== by 0x809DB9F: setEffectiveUser (main.c:500) ==9877== by 0x809E835: main (main.c:549) ==9877== ==9877== 36 bytes in 1 blocks are definitely lost in loss record 607 of 1,292 ==9877== at 0x4026864: malloc (vg_replace_malloc.c:236) ==9877== by 0x407BFD5: cap_init (in /lib/libcap.so.2.20) ==9877== by 0x407C0FB: cap_get_proc (in /lib/libcap.so.2.20) ==9877== by 0x80C651B: restoreCapabilities (tools.c:1367) ==9877== by 0x80C72FA: leave_suid (tools.c:644) ==9877== by 0x806DD75: clientOpenListenSockets (client_side.c:4971) ==9877== by 0x809DEBA: serverConnectionsOpen (main.c:330) ==9877== by 0x809E975: main (main.c:640) ==9877== ==9877== 36 bytes in 1 blocks are definitely lost in loss record 608 of 1,292 ==9877== at 0x4026864: malloc (vg_replace_malloc.c:236) ==9877== by 0x407BFD5: cap_init (in /lib/libcap.so.2.20) ==9877== by 0x407C0FB: cap_get_proc (in /lib/libcap.so.2.20) ==9877== by 0x80C651B: restoreCapabilities (tools.c:1367) ==9877== by 0x80C72FA: leave_suid (tools.c:644) ==9877== by 0x809730A: icpConnectionsOpen (icp_v2.c:419) ==9877== by 0x809DEBF: serverConnectionsOpen (main.c:331) ==9877== by 0x809E975: main (main.c:640) ==9877== ==9877== 36 bytes in 1 blocks are definitely lost in loss record 609 of 1,292 ==9877== at 0x4026864: malloc (vg_replace_malloc.c:236) ==9877== by 0x407BFD5: cap_init (in /lib/libcap.so.2.20) ==9877== by 0x407C0FB: cap_get_proc (in /lib/libcap.so.2.20) ==9877== by 0x80C651B: restoreCapabilities (tools.c:1367) ==9877== by 0x80C72FA: leave_suid (tools.c:644) ==9877== by 0x80ACBD2: snmpConnectionOpen (snmp_core.c:406) ==9877== by 0x809DEC4: serverConnectionsOpen (main.c:336) ==9877== by 0x809E975: main (main.c:640) ==9877== ==9877== 36 bytes in 1 blocks are definitely lost in loss record 610 of 1,292 ==9877== at 0x4026864: malloc (vg_replace_malloc.c:236) ==9877== by 0x407BFD5: cap_init (in /lib/libcap.so.2.20) ==9877== by 0x407C0FB: cap_get_proc (in /lib/libcap.so.2.20) ==9877== by 0x80C651B: restoreCapabilities (tools.c:1367) ==9877== by 0x80C72FA: leave_suid (tools.c:644) ==9877== by 0x80C76F9: writePidFile (tools.c:694) ==9877== by 0x809F06D: main (main.c:645) ==9877== ==9877== LEAK SUMMARY: ==9877== definitely lost: 180 bytes in 5 blocks ==9877== indirectly lost: 0 bytes in 0 blocks ==9877== possibly lost: 0 bytes in 0 blocks ==9877== still reachable: 27,015,550 bytes in 34,057 blocks ==9877== suppressed: 0 bytes in 0 blocks ==9877== Reachable blocks (those to which a pointer was found) are not shown. ==9877== To see them, rerun with: --leak-check=full --show-reachable=yes ==9877== 2011/10/12 01:25:38| Getting valgrind statistics (Cachemgr.cgi) Valgrind Report: Type Amount Leaked 180 <<<<<<<<<<<<<<<<<<<<<<<<------------------------- Dubious 0 Reachable 21180447 Suppressed 0 (Uname -a) Linux ubuntu-11 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux (Squid -v) Squid Cache: Version 2.7.STABLE9 configure options: '--prefix=/usr' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid' '--srcdir=.' '--datadir=${prefix}/share/squid' '--sysconfdir=/etc/squid' '--enable-async-io' '--enable-storeio=aufs,coss,null' '--enable-removal-policies=lru,heap' '--with-large-files' '--enable-snmp' '--with-valgrind-debug' (valgrind --version) valgrind-3.6.1 does anybody care to explain why 36 bytes appeared? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.