(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.Received on Tue Oct 11 2011 - 17:32:27 MDT
This archive was generated by hypermail 2.2.0 : Wed Oct 12 2011 - 12:00:02 MDT