Description of problem: Collectd (http://collectd.org/) leaks memory when used with the RDDtool in Fedora 8. This memory leak is fairely bad in a few hours all of the machine 4 gig + 4 gig or swap id leaked. Killing collectd free all memory back to syste,. Version-Release number of selected component (if applicable): collectd-4.2.3 & collectd-4.2.4 rrdtool 1.3-0.5.beta3.fc8 How reproducible: Every time. Steps to Reproduce: Download collectd. Compile and install. Run and watch memory go way. Additional info: Used complied collectd with debugging (gcc -g) and run with valgrind. [root@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.
Sounds like a similar problem to a bug reported in ganglia's bz: http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=170 This should probably also be filed with rrdtool's bug tracking system, if it isn't already. Its on my todo list, but if someone beats me to it, please add a ref to this bug too.
Upstream bug report: http://oss.oetiker.ch/rrdtool-trac/ticket/115
Upstream suggested some changes, which I've put into 1.3.0-0.6.beta3.fc9 (which will work just fine on fedora 8 too) for testing purposes. Please give it a spin, and if it resolves the problem, I'll push a proper update for fedora 8 as well. http://koji.fedoraproject.org/packages/rrdtool/1.3/0.6.beta3.fc9/
rrdtool-1.3-0.6.beta3.fc8 has been submitted as an update for Fedora 8
Hi Upgrading RRDtool to 0.6.beta3 seems to have fixed the problem. Will monitor over the next day or so and if no more problem will close this bug. Regards Daniel
rrdtool-1.3-0.6.beta3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.