[collectd] Memoy leak advice

[Florian Forster]

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 --
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20080125/987c87f4/attachment.pgp