[collectd] Memoy leak advice

[Daniel Rowe]

Hi

Just to let you guys know I have reported this to Fedora Bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=430879

A bug report has also been raised with RRDtool up stream by the Fedora
team.

Regards
Daniel

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 ;)
> 
> Regards,
> -octo
> 
> [*] 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 --