[collectd] Memoy leak advice

[Daniel Rowe]

> Hi Daniel,
> 
> On Thu, Jan 24, 2008 at 10:16:50PM +0900, Daniel Rowe wrote:
> > # Config file for collectd(1).
> 
> I'm using all the plugins you have loaded now myself, except the ntpd
> plugin. I'll run a test with it for an hour or two and see if I can
> reproduce a memory leak.
> 
> > With valgrind:
> 
> Sorry, but what you've posted is only summary: It clearly shows that
> theres quite a bunch of memory lost/leaked, but it doesn't say where.
> Could you please re-run the daemon with valgrind and the
> `--leak-check=full' option set? If the entire output is too big for the
> mailing list (there's a 40kByte limit) please put it on a web server
> somewhere and post a link to it or send it to me directory if you don't
> have access to some public storage.

Is this OK?

[root at bajor ~]# valgrind --leak-check=full /opt/collectd/sbin/collectd
-f -C /opt/collectd/etc/collectd.conf==32178== Memcheck, a memory error
detector.
==32178== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==32178== Using LibVEX rev 1732, a library for dynamic binary
translation.
==32178== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==32178== Using valgrind-3.2.3, a dynamic binary instrumentation
framework.
==32178== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.
==32178== For more details, rerun with: -v
==32178== 
==32178== 
==32178== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==32178== malloc/free: in use at exit: 1,851,004 bytes in 34,438 blocks.
==32178== malloc/free: 122,531 allocs, 88,093 frees, 110,629,923 bytes
allocated.
==32178== For counts of detected errors, rerun with: -v
==32178== searching for pointers to 34,438 not-freed blocks.
==32178== checked 683,752 bytes.
==32178== 
==32178== 2,183 (48 direct, 2,135 indirect) bytes in 1 blocks are
definitely lost in loss record 11 of 34
==32178==    at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==32178==    by 0x40EC89: yyparse (parser.y:179)
==32178==    by 0x40CEFC: oconfig_parse_fh (oconfig.c:43)
==32178==    by 0x40CF6C: oconfig_parse_file (oconfig.c:69)
==32178==    by 0x408652: cf_read_file (configfile.c:415)
==32178==    by 0x408A2A: cf_read (configfile.c:568)
==32178==    by 0x404429: main (collectd.c:373)
==32178== 
==32178== 
==32178== 72 bytes in 1 blocks are possibly lost in loss record 12 of 34
==32178==    at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==32178==    by 0x6367981: sprintf_alloc
(in /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636BAF1: (within /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636BE56: (within /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636C89E: (within /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636DCFA: _rrd_update
(in /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x6158C89: rrd_queue_thread (rrdtool.c:363)
==32178==    by 0x33E1806406: start_thread (in /lib64/libpthread-2.7.so)
==32178==    by 0x33E0CD4B0C: clone (in /lib64/libc-2.7.so)
==32178== 
==32178== 
==32178== 1,748,616 (79,680 direct, 1,668,936 indirect) bytes in 2,490
blocks are definitely lost in loss record 34 of 34
==32178==    at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==32178==    by 0x6367891: info_push (in /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636BB02: (within /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636BE56: (within /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636C89E: (within /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x636DCFA: _rrd_update
(in /usr/lib64/librrd_th.so.2.0.10)
==32178==    by 0x6158C89: rrd_queue_thread (rrdtool.c:363)
==32178==    by 0x33E1806406: start_thread (in /lib64/libpthread-2.7.so)
==32178==    by 0x33E0CD4B0C: clone (in /lib64/libc-2.7.so)
==32178== 
==32178== LEAK SUMMARY:
==32178==    definitely lost: 79,728 bytes in 2,491 blocks.
==32178==    indirectly lost: 1,671,071 bytes in 31,213 blocks.
==32178==      possibly lost: 72 bytes in 1 blocks.
==32178==    still reachable: 100,133 bytes in 733 blocks.
==32178==         suppressed: 0 bytes in 0 blocks.
==32178== Reachable blocks (those to which a pointer was found) are not
shown.



> Regards,
> -octo
> 
> P. S.: First results don't seem like I'm able to reproduce the memory
> leak using the ntpd plugin:
> -- 8< --
>  octo at leeloo:~ $ while true
>  > do
>  > echo -n "`date`: "
>  > cat /proc/31056/statm | cut -d ' ' -f 2
>  > sleep 60
>  > done
>  Thu Jan 24 14:45:43 CET 2008: 240
>  Thu Jan 24 14:46:43 CET 2008: 240
>  Thu Jan 24 14:47:43 CET 2008: 240
>  Thu Jan 24 14:48:43 CET 2008: 240
>  Thu Jan 24 14:49:43 CET 2008: 240
>  Thu Jan 24 14:50:43 CET 2008: 240
> -- >8 --

Regards
Daniel