lib: compile liblttng-ctl as C++ Same as the previous commits, but compile the liblttng-ctl library as C++ code (while still offering a C interface). Some exported global variables (for example in deprecated-symbols.cpp) have to be made non-const, otherwise we get: CXX deprecated-symbols.lo /home/simark/src/lttng-tools/src/lib/lttng-ctl/deprecated-symbols.cpp:21:33: error: ‘visibility’ attribute ignored [-Werror=attributes] 21 | LTTNG_EXPORT const char * const config_element_pid_tracker; | ^~~~~~~~~~~~~~~~~~~~~~~~~~ I think this is related to the fact that const global variables automatically have internal linkage in C++. Despite using -export-symbols in src/lib/lttng-ctl/Makefile.am, some new ELF symbols become exposed. It could be related to this, in the ld man page: --retain-symbols-file does not discard undefined symbols, or symbols needed for relocations. One new symbol I see, for example, is `_Z16connect_sessiondv`. Looking at liblttng-ctl.so, I indeed see a relocation for this symbol: 000000000010b778 0000053e00000007 R_X86_64_JUMP_SLOT 00000000000314a2 _Z16connect_sessiondv + 0 And that would explain why the linker keeps that symbol visible. This is related to the entry for this function in the procedure linkage table. I'm not entirely sure why these functions didn't generate a PLT entry in C, but do in C++. To avoid these new symbols, build everything with -fvisibility=hidden and -fvisibility-inlines-hidden, and tag functions we really want to export with LTTNG_EXPORT, a new macro defined to __attribute__((visibility("default"))). This macro is publicly visible, because it has to be used in distributed header files (although it's of no use for users of liblttng-ctl). Change-Id: Ie51bf0a2edfb87e5f46f9c39eed5309d9f8c41d6 Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Clean-up: lttngctl: copy string using strdup instead of asprintf Use strdup to copy a string instead of using the formatting utilities. The code of the function is also adapted to follow the coding standards. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I13328737e42a0287a7402761f75c67eef0dbdfdd
Fix: lttng-ctl: tracing_group memory leaks Observed issue ============== liblttng-ctl leaks memory if `lttng_set_tracing_group` is called at least 1 time by an API client. joraj@~/lttng/master/lttng-tools-dev [master][]$ valgrind --leak-check=full lttng --group=joraj list ==24823== Memcheck, a memory error detector ==24823== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==24823== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==24823== Command: lttng --group=joraj list ==24823== Error: No session daemon is available ==24823== ==24823== HEAP SUMMARY: ==24823== in use at exit: 8 bytes in 1 blocks ==24823== total heap usage: 55 allocs, 54 frees, 87,023 bytes allocated ==24823== ==24823== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==24823== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==24823== by 0x4BA7DC7: __vasprintf_internal (vasprintf.c:71) ==24823== by 0x4C4B742: __asprintf_chk (asprintf_chk.c:34) ==24823== by 0x48687D9: asprintf (stdio2.h:181) ==24823== by 0x48687D9: lttng_set_tracing_group (lttng-ctl.c:2620) ==24823== by 0x4011B89: call_init.part.0 (dl-init.c:72) ==24823== by 0x4011C90: call_init (dl-init.c:30) ==24823== by 0x4011C90: _dl_init (dl-init.c:119) ==24823== by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so) ==24823== by 0x2: ??? ==24823== by 0x1FFEFFFCFE: ??? ==24823== by 0x1FFEFFFD04: ??? ==24823== by 0x1FFEFFFD12: ??? ==24823== ==24823== LEAK SUMMARY: ==24823== definitely lost: 8 bytes in 1 blocks ==24823== indirectly lost: 0 bytes in 0 blocks ==24823== possibly lost: 0 bytes in 0 blocks ==24823== still reachable: 0 bytes in 0 blocks ==24823== suppressed: 0 bytes in 0 blocks ==24823== ==24823== For lists of detected and suppressed errors, rerun with: -s ==24823== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Cause ===== The allocated pointer in the library constructor is not freed on subsequent assignation. Solution ======== Free the pointer. Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: Ie1d4c45df2764a88c74d56de691783df9215633c
Cleanup: namespace 'align' macros Remove the duplicate ALIGN() and ALIGN_TO() macro and replace them with namespaced variants 'lttng_align_ceil()' and 'lttng_align_floor()'. Change-Id: I683baccb4e97874e647cf557bad9653a336f4a6d Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
liblttng-ctl: use export list to define exported symbols Symbols are currently exported by default by liblttng-ctl.so (usable by other shared libraries / programs using liblttng-ctl.so), so we must use LTTNG_HIDDEN on all symbols that are meant to be internal to liblttng-ctl.so. Of course, this is easy to forget, so over the years many symbols that were not meant to be exported were exported, and must now stay exported to avoid breaking the ABI. As explained here [1], a better method is to make symbols hidden by default, and mark those we want to be exported as such. I have tried to use this, but when subsequently converting the code to C++, I have noticed that some symbols related to the STL were exported anyway, which is bad. The other alternative, implemented in this patch, is to use an explicit symbol export list [2], using libtool's -export-symbols (which uses the linker's -version-script option). Only the symbols listed here are exported. So, in practice, this patch: - Adds an liblttng-ctl.sym file with the list of exported symbols and adjusts the Makefile to use the -export-symbol option - Removes LTTNG_HIDDEN and all its uses abidiff shows no changes for liblttng-ctl.so between before and after this patch. [1] https://gcc.gnu.org/wiki/Visibility [2] https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode Change-Id: I5d8c558303894b0ad8113c6e52f79a053bb580e1 Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Force usage of assert() condition when NDEBUG is defined Reuse the BT2 approach to force the usage of the assertion condition even when assert() are removed by the NDEBUG define. See `BT_USE_EXPR()` macro and documentation in Babeltrace commit[0]: commit 1778c2a4134647150b199b2b57130817144446b0 Author: Philippe Proulx <eeppeliteloop@gmail.com> Date: Tue Apr 21 11:15:42 2020 -0400 lib: assign a unique ID to each pre/postcond. and report it on failure 0: https://github.com/efficios/babeltrace/commit/1778c2a4134647150b199b2b57130817144446b0 Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I3844b6ae7e95952d90033898397ac936540b785c
Fix: appending unallocated data from beyond exclusion entries Issue ===== If an exclusion string is smaller than the `LTTNG_SYMBOL_NAME_LEN` integer, the `lttng_dynamic_buffer_append()` call will append unallocated data to the buffer. Fix === Use the `exclusion_len` value to copy the actual exclusion and pad the remaining bytes with zeros. Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com> Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I04c6681c28e82de29791541eb490158db9e503d0
Fix: lttng-ctl: erroneous check if user is part of the tracing group in_tgroup is set to `-1` whenever the current user is not part of the tracing group _or_ if an error occurred while looking up if the user is part of the tracing group. In other words, the value '0' is unused. in_tgroup must be explicitly checked against '1' and can't be assumed to behave as a boolean value. This is _not_ a security issue: if the user is not part of the tracing group, she will fail to open the root session damon's socket because of the kernel-side permission checking. However, the behaviour of the lttng client (and error reporting) will be confusing. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I614da0123d0546c5f54f121e8ed9716d6e292400
Fix: lttng-ctl: appending to dynamic buffer invalidates its data member Issue ===== The following commands fail: lttng add-trigger --id T0 --condition on-event -u some-event --action snapshot-session ze-session3 --path /some/path lttng remove-trigger T0 Error: Attempt to create buffer view from another view with invalid length (length > space left after offset in source): source size = 0, offset in source = 0, length = 25 Error: Invalid trigger received as part of command payload Valgrind complains in the following way: ==706109== ==706109== Invalid write of size 4 ==706109== at 0x489FED7: lttng_unregister_trigger (lttng-ctl.c:3281) ==706109== by 0x43C175: cmd_remove_trigger (remove_trigger.c:171) ==706109== by 0x43F56B: handle_command (lttng.c:237) ==706109== by 0x43E9B1: parse_args (lttng.c:421) ==706109== by 0x43E158: main (lttng.c:470) ==706109== Address 0x73d8d20 is 4,688 bytes inside a block of size 16,384 free'd ==706109== at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==706109== by 0x48C1478: lttng_dynamic_buffer_set_capacity (dynamic-buffer.c:166) ==706109== by 0x48C138C: lttng_dynamic_buffer_append (dynamic-buffer.c:55) ==706109== by 0x48E3325: lttng_snapshot_output_serialize (snapshot.c:120) ==706109== by 0x48B46C3: lttng_action_snapshot_session_serialize (snapshot-session.c:173) ==706109== by 0x48B1FB2: lttng_action_serialize (action.c:130) ==706109== by 0x48B2DFE: lttng_action_group_serialize (group.c:165) ==706109== by 0x48B1FB2: lttng_action_serialize (action.c:130) ==706109== by 0x48ECE66: lttng_trigger_serialize (trigger.c:372) ==706109== by 0x489FEA0: lttng_unregister_trigger (lttng-ctl.c:3275) ==706109== by 0x43C175: cmd_remove_trigger (remove_trigger.c:171) ==706109== by 0x43F56B: handle_command (lttng.c:237) ==706109== Block was alloc'd at ==706109== at 0x483B723: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==706109== by 0x483E017: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==706109== by 0x48C1478: lttng_dynamic_buffer_set_capacity (dynamic-buffer.c:166) ==706109== by 0x48C138C: lttng_dynamic_buffer_append (dynamic-buffer.c:55) ==706109== by 0x489FE66: lttng_unregister_trigger (lttng-ctl.c:3263) ==706109== by 0x43C175: cmd_remove_trigger (remove_trigger.c:171) ==706109== by 0x43F56B: handle_command (lttng.c:237) ==706109== by 0x43E9B1: parse_args (lttng.c:421) ==706109== by 0x43E158: main (lttng.c:470) `lttng_unregister_trigger` samples the address of the lsm header in the message payload. However, it does so before calling `lttng_trigger_serialize()` which may increase the underlying buffer's size (and cause a realloc()). Most of the time the message buffer is large enough _or_ its realloc yields the same address which hid the problem. However, I stumbled on a case (a trigger which snapshots to a location) where the realloc ends-up returning a completely different address, causing invalid data to be sent to the session daemon. Solution ======== Sample the lsm header address after the serialization of the trigger. Note ==== An identical fix was done for the `lttng_register_trigger` function in: commit b22f4f54e95ae13edda1d4d5efd1e4845a6319c4 Author: Jérémie Galarneau <jeremie.galarneau@efficios.com> Date: Thu Feb 18 18:13:19 2021 -0500 Fix: lttng-ctl: appending to dynamic buffer invalidates its data member I reuse the bug explanation for this commit message. Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: Ic50c96dcada9e0595b0fab1d2f357c183b53e1de
Fix: lttng_destroy_session_no_wait: return 0 on success lttng_destroy_session_no_wait() is supposed to behave like lttng_destroy_session(): > Return 0 on success else a negative LTTNg error code. However, it returns LTTNG_OK on success. Make it return 0 instead. Signed-off-by: Christophe Bedard <christophe.bedard@apex.ai> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: If51f6a2cc3ca77237f7cbac806c5206a807dadf5
Clean-up: liblttng-ctl: fix -Wshadow error in lttng_enable_event_with_exclusions The local variable `handle` shadows the parameter, rename the local variable. Change-Id: Ic1f3b8ae9fd6ac356eeee691c0328d6e8e1d0216 Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
common: move bytecode utilities from filter to its own file We'll want to re-use the filter bytecode to implement the trigger event rule condition field captures. This is a preparatory patch that moves some filter bytecode code in a location that is not filter-specific, so it can be used for both filters and captures. The content of common/filter/filter-bytecode.h is moved to common/bytecode/bytecode.h. Some declarations for the various bytecode helpers are added to that file. The implementation for these helpers is moved from common/filter/filter-visitor-generate-bytecode.c to common/bytecode/bytecode.c. The content of src/common/bytecode is built as a library, so it can be used by the filter-grammar-test program. A following patch renames the content of bytecode/bytecode.h to remove the "filter" part. The rest of the changes is just to adapt the code to the changes mentioned above. Change-Id: Id602c9046bdc76791026c5b5a928387145d18e43 Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Depends-on: lttng-ust: I5a800fc92e588c2a6a0e26282b0ad5f31c044479
lttng: Add remove-trigger command Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I323ddc181c9214dcf4ae66e23a382451f6582fff Depends-on: lttng-ust: I5a800fc92e588c2a6a0e26282b0ad5f31c044479
Fix: lttng-ctl: appending to dynamic buffer invalidates its data member `lttng_register_trigger` samples the address of the lsm header in the message payload. However, it does so before calling `lttng_trigger_serialize()` which may increase the underlying buffer's size (and cause a realloc()). Most of the time the message buffer is large enough _or_ its realloc yields the same address which hid the problem. However, I stumbled on a case (a trigger which snapshots to a long location) where the realloc ends-up returning a completely different address, causing invalid data to be sent to the session daemon. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I8e4323dac778bc2a1af7b6e2cca42f6521abaee2
Fix: liblttng-ctl: unreported truncations when copying strings gcc 10.2 reports a large number of string truncation warning in liblttng-ctl. Replace the uses of lttng_ctl_copy_string() util by lttng_strncpy() (handling the null source case when applicable) and report the truncations when they occur. Example gcc warning: lttng-ctl.c:86:3: warning: ‘strncpy’ output may be truncated copying 254 bytes from a string of length 254 [-Wstringop-truncation] Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: Icca5f4c2490c6796b451999d7694db8597bae719
trigger: consider domain on register and unregister This allows the sessiond to inform the client if a trigger that requires a particular domain (event rule based condition, for example) is at all valid. This is useful to fail early when a trigger being registered requires an unavailable tracer. Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I660937e64b294f6239ba15faeef705438a93a41a