[collectd] Memoy leak advice
lists at fathom13.com
Tue Feb 5 11:14:45 CET 2008
Just to let you guys know I have reported this to Fedora Bugzilla.
A bug report has also been raised with RRDtool up stream by the Fedora
On Fri, 2008-01-25 at 16:17 +0100, Florian Forster wrote:
> Hi Daniel,
> On Fri, Jan 25, 2008 at 11:07:19PM +0900, Daniel Rowe wrote:
> > ==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.
> what version of librrd do you have installed? The above output indicates
> that memory is lost inside the rrd library. I tried to check the code
> around the call to the `info_push' function, but soon lost track of all
> allocated memory. [*]
> Can you please replace the rrdtool plugin with the csv plugin to double
> check if really the rrdtool plugin is the one to blame? If that should
> be the case you should try the newest version of rrdtool and see if the
> problem still exists.
> Please let me know what you find out in any case - I don't sleep well
> with a potential memory leak in collectd ;)
> [*] For example, in _rrd_update the following is done:
> -- 8< --
> int _rrd_update (..., info_t *pcdp_summary)
> /* ... */
> * write_RRA_row calls info_push which allocates a new `info_t' and
> * appends it to the passed in `info_t' (if it is not NULL) and
> * returns a pointer to the newly allocated memory, i. e. the tail of
> * the linked list. As far as I can tell pointers to the preceeding
> * elements are lost unless they're held outside of `_rrd_update'.
> pcdp_summary = write_RRA_row (..., pcdp_summary, ...);
> /* ...; pcdp_summary is never touched again. */
> * Let the fun begin: We pass in a NULL-pointer, so NULL will be passed
> * to `info_push' which allocated a memory and returns a pointer. This
> * pointer is passed to `info_push' again which returns a new pointer
> * (to new memory) which replaces the original `pcdp_summary'. That
> * memory is (as far as I see it) lost, etc.. Given the levels of
> * indirection and the, uhm, suboptimal indentation I'm not even
> * positive the position in the code is actually in a loop.
> _rrd_update (..., NULL);
> -- >8 --
More information about the collectd