Issue observed
--------------
ASAN reports the following leak when running the
tests/regression/tools/context/test_ust.py test suite:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f32e5ae0cd1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x5653e1092088 in zmalloc_internal ../../../src/common/macros.hpp:60
#2 0x5653e10922b3 in char* calloc<char>(unsigned long) string-utils/../macros.hpp:113
#3 0x5653e119d68f in get_context_type commands/add_context.cpp:1012
#4 0x5653e119ddf5 in cmd_add_context(int, char const**) commands/add_context.cpp:1059
#5 0x5653e11e12e7 in handle_command /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:237
#6 0x5653e11e2027 in parse_args /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:427
#7 0x5653e11e24e1 in _main /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:474
#8 0x5653e11e25bd in main /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:485
#9 0x7f32e3e3984f (/usr/lib/libc.so.6+0x2384f) (BuildId:
2f005a79cd1a8e385972f5a102f16adba414d75e)
Direct leak of 5 byte(s) in 1 object(s) allocated from:
#0 0x7f32e5ae0cd1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x5653e1092088 in zmalloc_internal ../../../src/common/macros.hpp:60
#2 0x5653e10922b3 in char* calloc<char>(unsigned long) string-utils/../macros.hpp:113
#3 0x5653e119d2ae in get_context_type commands/add_context.cpp:1003
#4 0x5653e119ddf5 in cmd_add_context(int, char const**) commands/add_context.cpp:1059
#5 0x5653e11e12e7 in handle_command /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:237
#6 0x5653e11e2027 in parse_args /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:427
#7 0x5653e11e24e1 in _main /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:474
#8 0x5653e11e25bd in main /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:485
#9 0x7f32e3e3984f (/usr/lib/libc.so.6+0x2384f) (BuildId:
2f005a79cd1a8e385972f5a102f16adba414d75e)
Cause
-----
The context and provider names are dynamically allocated by
get_context_type() and stored in ctx_type. However, destroy_ctx_type()
never frees those members when the structure is of type
CONTEXT_APP_CONTEXT.
Solution
--------
Free both names when an application context type is destroyed.
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I86dde1eed9f0cc63499c936cf373b094168035e2