Bug 430879 - Memory leak in RRDtool with collectd
Memory leak in RRDtool with collectd
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rrdtool (Show other bugs)
8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-30 07:30 EST by Daniel Rowe
Modified: 2008-02-12 23:48 EST (History)
0 users

See Also:
Fixed In Version: 1.3-0.6.beta3.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 23:48:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Rowe 2008-01-30 07:30:47 EST
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.
Comment 1 Jarod Wilson 2008-02-04 14:39:27 EST
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.
Comment 2 Jarod Wilson 2008-02-04 16:36:04 EST
Upstream bug report:

http://oss.oetiker.ch/rrdtool-trac/ticket/115
Comment 3 Jarod Wilson 2008-02-05 10:29:41 EST
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/
Comment 4 Fedora Update System 2008-02-05 17:36:29 EST
rrdtool-1.3-0.6.beta3.fc8 has been submitted as an update for Fedora 8
Comment 5 Daniel Rowe 2008-02-07 09:05:19 EST
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
Comment 6 Fedora Update System 2008-02-12 23:48:16 EST
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.

Note You need to log in before you can comment on or make changes to this bug.