[lttng-dev] Mem leak in lttng_ust lttng_probes_get_event_list()

[Aravind HT]

Hi,

I have seen that the RES mem from TOP increases over time for an
application that
is being traced. When analyzed with valgrind, I see the following

==12429== 175,824 bytes in 594 blocks are possibly lost in loss record 30
of 30
==12429==    at 0x4C29810: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12429==    by 0x54AF21E: calloc (in
/usr/lib64/liblttng-ust-libc-wrapper.so.0.0.0)
==12429==    by 0x526C27B: lttng_probes_get_event_list (in
/usr/lib64/liblttng-ust.so.0.0.0)
==12429==    by 0x526AD9E: ??? (in /usr/lib64/liblttng-ust.so.0.0.0)
==12429==    by 0x5267FAF: ??? (in /usr/lib64/liblttng-ust.so.0.0.0)
==12429==    by 0x503CFE2: start_thread (pthread_create.c:312)
==12429==    by 0x579BAFC: clone (clone.S:111)


There is a memleak seen when lttng_probes_get_event_list() gets called
during listing of
trace points, example "lttng list -u". Each time
lttng_probes_get_event_list() gets called,
objd_alloc() is called and a new list of trace points generated in
lttng_probes_get_event_list()
and stored.
This entry in the objd_table is not reused when "lttng list -u" gets called
again in the future
and is also not removed until the application exits resulting in memory
consumption.

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.

Regards,
Aravind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160328/e2613245/attachment.html>