<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br data-mce-bogus="1"></div><div>Please open an issue on the bug tracker with all the information requested</div><div>in the bug reporting guidelines. See https://bugs.lttng.org/<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Mathieu<br data-mce-bogus="1"></div><div><br></div><span id="zwchr" data-marker="__DIVIDER__">----- On Mar 28, 2016, at 2:09 AM, Aravind HT <aravind.ht@gmail.com> wrote:<br></span><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr">Hi,<br><div><div>I have seen that the RES mem from TOP increases over time for an application that</div><div>is being traced. When analyzed with valgrind, I see the following</div><br><div>==12429== 175,824 bytes in 594 blocks are possibly lost in loss record 30 of 30</div><div>==12429== at 0x4C29810: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)</div><div>==12429== by 0x54AF21E: calloc (in /usr/lib64/liblttng-ust-libc-wrapper.so.0.0.0)</div><div>==12429== by 0x526C27B: lttng_probes_get_event_list (in /usr/lib64/liblttng-ust.so.0.0.0)</div><div>==12429== by 0x526AD9E: ??? (in /usr/lib64/liblttng-ust.so.0.0.0)</div><div>==12429== by 0x5267FAF: ??? (in /usr/lib64/liblttng-ust.so.0.0.0)</div><div>==12429== by 0x503CFE2: start_thread (pthread_create.c:312)</div><div>==12429== by 0x579BAFC: clone (clone.S:111)</div><br><br><div>There is a memleak seen when lttng_probes_get_event_list() gets called during listing of </div><div>trace points, example "lttng list -u". Each time lttng_probes_get_event_list() gets called,</div><div>objd_alloc() is called and a new list of trace points generated in lttng_probes_get_event_list()</div><div>and stored.</div><div>This entry in the objd_table is not reused when "lttng list -u" gets called again in the future </div><div>and is also not removed until the application exits resulting in memory consumption. </div><br><div>I can see that the objd_table is meant to be used as a cache but somehow the full implementation is not present..is this a work still in progress ? If not, to solve this, whenever lttng_probes_get_event_list() is called, we could check if we have results available in the objd_table from an earlier call for a particular owner and name and re-use it. </div></div><br><div>Regards,</div><div>Aravind.</div></div>
<br>_______________________________________________<br>lttng-dev mailing list<br>lttng-dev@lists.lttng.org<br>https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<br></blockquote></div><br><div data-marker="__SIG_POST__">-- <br></div><div>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com</div></div></body></html>