Mathieu Desnoyers [Mon, 10 Oct 2022 15:53:50 +0000 (16:53 +0100)] 
Fix: populate possible cpus array len cache with fd tracker lock
get_possible_cpus_array_len internally opens and closes file
descriptors. Initialize the cache with fd tracker lock held to prevent
concurrent use of close/closeall/closefrom.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib16c73f11af0b0cb163b38b0b096a86f6ae86325
Mathieu Desnoyers [Tue, 4 Oct 2022 20:25:52 +0000 (16:25 -0400)]
Fix: Use 2.12 custom mutex nest getter
Eliminate the following deadlock by calling libc close directly when
called from within the 2.12 fd tracker locking. The 2.13 locks always
need to be taken outside of the 2.12 locks. In the scenario below,
Thread 3 (lttng-ust 2.12 listener thread) takes the locks in the wrong
order.
This fix depends on custom commit "Add ust fd mutex nesting getter" in
LTTng-UST 2.12.
Thread 3 (Thread 0x7f7679247700 (LWP 621683) "hello-ust"):
#0 __lll_lock_wait (futex=futex@entry=0x7f767a392b60 <ust_safe_guard_fd_mutex>, private=0) at lowlevellock.c:52
#1 0x00007f767a39d843 in __GI___pthread_mutex_lock (mutex=0x7f767a392b60 <ust_safe_guard_fd_mutex>) at ../nptl/pthread_mutex_lock.c:80
-> 2.13 locks fd tracker
2.13 #2 0x00007f767a37ff82 in lttng_ust_lock_fd_tracker_orig () at fd-tracker.c:163
2.13 #3 0x00007f767a380b66 in lttng_ust_safe_close_fd_orig (fd=3, close_cb=0x7f767a56b070 <__GI___close>) at fd-tracker.c:385
2.13 #4 0x00007f767a6e5557 in close (fd=3) at lttng-ust-fd.c:101
2.12 #5 0x00007f767a297e7d in ustcomm_connect_unix_sock (pathname=0x7f767a32bc64 <local_apps+36> "/home/compudj/.lttng/lttng-ust-sock-8", timeout=3000) at lttng-ust-comm.c:157
-> 2.12 listener thread locks fd tracker
-> 2.12 listener thread locks ust_lock
2.12 #6 0x00007f767a2a1f77 in ust_listener_thread (arg=0x7f767a32bc40 <local_apps>) at lttng-ust-comm.c:1591
#7 0x00007f767a39aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8 0x00007f767a57aaef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 2 (Thread 0x7f7678a46700 (LWP 621682) "hello-ust"):
#0 __lll_lock_wait (futex=futex@entry=0x7f767a32f780 <ust_mutex>, private=0) at lowlevellock.c:52
#1 0x00007f767a39d843 in __GI___pthread_mutex_lock (mutex=0x7f767a32f780 <ust_mutex>) at ../nptl/pthread_mutex_lock.c:80
2.12 #2 0x00007f767a29da59 in ust_lock () at lttng-ust-comm.c:167
2.12 #3 0x00007f767a2a1d95 in ust_listener_thread (arg=0x7f767a329be0 <global_apps>) at lttng-ust-comm.c:1558
#4 0x00007f767a39aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#5 0x00007f767a57aaef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7f767a33a040 (LWP 621681) "hello"):
#0 __lll_lock_wait (futex=futex@entry=0x7f767a32f720 <ust_safe_guard_fd_mutex>, private=0) at lowlevellock.c:52
#1 0x00007f767a39d843 in __GI___pthread_mutex_lock (mutex=0x7f767a32f720 <ust_safe_guard_fd_mutex>) at ../nptl/pthread_mutex_lock.c:80
-> 2.12 lock fd tracker
2.12 #2 0x00007f767a29c37c in lttng_ust_lock_fd_tracker () at lttng-ust-fd-tracker.c:153
2.12 #3 0x00007f767a29ceba in lttng_ust_safe_close_fd (fd=4, close_cb=0x7f767a56b070 <__GI___close>) at lttng-ust-fd-tracker.c:341
2.13 #4 0x00007f767a380b06 in lttng_ust_safe_close_fd_chain (fd=4, close_cb=0x7f767a56b070 <__GI___close>) at fd-tracker.c:348
2.13 #5 0x00007f767a380b5c in lttng_ust_safe_close_fd_orig (fd=4, close_cb=0x7f767a56b070 <__GI___close>) at fd-tracker.c:379
2.13 #6 0x00007f767a6e5557 in close (fd=4) at lttng-ust-fd.c:101
-> 2.13 lock fd tracker
2.13 #7 0x00007f767a43b5e6 in lttng_ust_elf_destroy (elf=0x55b870f044c0) at elf.c:352
2.13 #8 0x00007f767a3f2797 in get_elf_info (bin_data=0x7ffd5481ef70) at lttng-ust-statedump.c:296
2.13 #9 0x00007f767a3f283f in extract_baddr (bin_data=0x7ffd5481ef70) at lttng-ust-statedump.c:319
2.13 #10 0x00007f767a3f3173 in extract_bin_info_events (info=0x7ffd5481fff0, size=64, _data=0x7ffd54820098) at lttng-ust-statedump.c:518
#11 0x00007f767a5b3ad5 in __GI___dl_iterate_phdr (callback=0x7f767a3f2f5a <extract_bin_info_events>, data=0x7ffd54820098) at dl-iteratephdr.c:75
2.13 #12 0x00007f767a3f32c5 in lttng_ust_dl_update_orig (ip=0x7f767a3cb599 <lttng_ust_ctor+683>) at lttng-ust-statedump.c:574
2.13 #13 0x00007f767a3f33f7 in lttng_ust_statedump_init () at lttng-ust-statedump.c:638
2.13 #14 0x00007f767a3cb599 in lttng_ust_ctor () at lttng-ust-comm.c:2246
2.13 #15 0x00007f767a3ccaad in lttng_ust_after_fork_child (restore_sigset=0x7ffd548207e0) at lttng-ust-comm.c:2577
2.13 #16 0x00007f767a6f687f in fork () at ustfork.c:271
#17 0x000055b8705f1034 in make_child ()
#18 0x000055b8705daacc in execute_command_internal ()
#19 0x000055b8705ddcf5 in execute_command ()
#20 0x000055b8705df951 in ?? ()
#21 0x000055b8705daf79 in execute_command_internal ()
#22 0x000055b8705ddcf5 in execute_command ()
#23 0x000055b8705c49db in reader_loop ()
#24 0x000055b8705c3668 in main ()
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ife72c3532dde1357c6c7937aa4c5d8135fd52e84
Mathieu Desnoyers [Tue, 4 Oct 2022 17:05:01 +0000 (13:05 -0400)]
Fix: ust-fork: reverse order of "after" callbacks
The "after" callbacks restore the pthread cancelstate to the prior
state, and warn on the application console when LTTNG_UST_DEBUG=1 is set
if the cancelstate restored does not match the cancelstate saved.
It is therefore important that we keep the following order:
- begin callback (2.13)
- begin callback (2.12)
...
- after callback (2.12)
- after callback (2.13)
to preserve the correct nesting of saved/restored pthread cancelstate.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Id95792654d514e0dcd09c00ff5dc0d220fb27f87
Mathieu Desnoyers [Tue, 4 Oct 2022 17:04:38 +0000 (13:04 -0400)]
Fix: lazily dlopen 2.12 lttng-ust from liblttng-ust-fd.so symbol overrides
Fix warnings:
/usr/lib64/liblttng-ust-common.so.1: undefined symbol: lttng_ust_safe_close_fd
Lazily dlopen liblttng-ust.so.0 when close/fclose are used early before
execution of liblttng-ust-fd.so's constructor, and use it to perform the
perform the required dlsym() lookups to find the 2.12 LTTng-UST symbols.
Also perform these dlopen/dlsym intialization operations from
liblttng-ust-fd.so's contructor, so if close() is used from a signal
handler, it does not have to invoke dlopen()/dlsym() which are not
async-signal-safe.
Add compiler #error around closefrom() which is only emitted on Solaris
and BSDs, and not relevant to the 2.13 custom upgrade scope.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I292434328f512bbb284c97f6a6170edbeef7c222
Michael Jeanson [Thu, 29 Sep 2022 16:05:55 +0000 (16:05 +0000)] 
Custom upgrade: disable ABI conflict tests
This test is not appropriate for this custom upgrade branch.
Change-Id: I1b97a9f52fb94a65a65db65f34a84abf8bb2a874
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Mathieu Desnoyers [Wed, 15 Jun 2022 15:13:35 +0000 (11:13 -0400)]
Custom upgrade: chain load liblttng-ust-{fd,fork}.so.0 with dlopen
dlopen liblttng-ust.so.0 in the constructor of the interposer librairies
and explicitly call the symbols from this library when appropriate.
As a side-note, chain linking the interposer ld_preload librairies on
their previous SONAME0 versions doesn't work as expected because the
order of the symbol resolution with dlsym always favors the preloaded
library symbols. This is why explicit use of dlopen/dlsym is favored
instead.
Change-Id: Ie8802134c3037cfd431a949f469d3e64e958888b
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Mathieu Desnoyers [Mon, 13 Jun 2022 19:54:48 +0000 (15:54 -0400)]
Custom upgrade: remove canary symbols for builds without LTTNG_UST_CUSTOM_UPGRADE_CONFLICTING_SYMBOLS
When the symbols clashing with lttng-ust 2.12 are renamed to be suffixed
with "1", it becomes possible to run lttng-ust 2.12 and 2.13 in the same
process.
Leave those sanity checks in place for builds with
LTTNG_UST_CUSTOM_UPGRADE_CONFLICTING_SYMBOLS defined.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I8664884bdc60043bf28b923786a16ee2ee3301a8
Mathieu Desnoyers [Mon, 13 Jun 2022 19:06:15 +0000 (15:06 -0400)]
Custom upgrade: suffix getcpu plugin symbol with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I44e451258ff1570bf5f6bbb40650a6059c72811b
Mathieu Desnoyers [Mon, 13 Jun 2022 19:03:47 +0000 (15:03 -0400)]
Custom upgrade: suffix clock plugin symbols with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: If197536aec2c555d92e210e8b44d68019c5ddceb
Mathieu Desnoyers [Mon, 13 Jun 2022 18:56:53 +0000 (14:56 -0400)]
Custom upgrade: suffix cancelstate symbols with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I107cd5c0a63c9b16498580baf9906520c39d4bfc
Mathieu Desnoyers [Mon, 13 Jun 2022 18:54:35 +0000 (14:54 -0400)]
Custom upgrade: fd tracker: suffix exported symbols with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I465a926d741d5c7f5c6db2cc29d1fc84ab7e4aa2
Mathieu Desnoyers [Mon, 13 Jun 2022 18:48:44 +0000 (14:48 -0400)]
Custom upgrade: suffix lttng_ust_strerror with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I8a4a3017402fe7b9316b451b07bc86738576db91
Mathieu Desnoyers [Mon, 13 Jun 2022 18:42:24 +0000 (14:42 -0400)]
Custom upgrade: suffix lttng_ust_loaded with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I8efb7b3e3b291b3716762a1a56c131263915ef4c
Mathieu Desnoyers [Mon, 13 Jun 2022 18:27:06 +0000 (14:27 -0400)]
Custom upgrade: suffix lttng_ust_dl_update with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I42eb70f5d7a6336d64483af7a5293b882e2f6639
Mathieu Desnoyers [Mon, 13 Jun 2022 18:24:14 +0000 (14:24 -0400)]
Custom upgrade: suffix lttng_ust_context_provider_{,un}register with 1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib6adae1cab526f2407483223c8dcbb1ba79c263f
Mathieu Desnoyers [Mon, 13 Jun 2022 19:25:40 +0000 (15:25 -0400)]
Custom upgrade: wire up configure --enable-custom-upgrade-conflicting-symbols
This custom configure switch allows selecting between those two
behaviors for symbols which clash between lttng-ust 2.12 and 2.13:
Disabled (default): only emit and use symbols with "1" suffix. This
is meant to be used alonside lttng-ust 2.12.
Enabled: emit both symbols with and without "1" suffix, and use the
symbol without suffix. This is meant to be used after there are no
more users of lttng-ust 2.12 to gradually transition back to an upstream
lttng-ust 2.13 as applications are rebuilt.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I7ed02b2f0f9bd8c7b7b24fce28d2f23d61c970a3
Mathieu Desnoyers [Fri, 30 Sep 2022 18:30:12 +0000 (14:30 -0400)]
Version 2.13.5
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I9df6c2d875ba28764fdbc2c244886936aab63fc5
Mathieu Desnoyers [Fri, 30 Sep 2022 14:20:29 +0000 (10:20 -0400)]
Fix: bytecode validator: reject specialized load field/context ref instructions
Reject specialized load ref and get context ref instructions so a
bytecode crafted with nefarious intent cannot read a memory area larger
than the memory targeted by the instrumentation.
This prevents bytecode received from the session daemon from performing
out of bound memory accesses and from disclosing the content of
application memory beyond what has been targeted by the instrumentation.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ica16b97167d391d86e73b05fbf0210ff52b9c9f1
Mathieu Desnoyers [Thu, 29 Sep 2022 19:37:47 +0000 (15:37 -0400)]
Fix: bytecode validator: reject specialized load instructions
Reject specialized load instructions so a bytecode crafted with
nefarious intent cannot read a memory area larger than the memory
targeted by the instrumentation.
This prevents bytecode received from the session daemon from performing
out of bound memory accesses and from disclosing the content of
application memory beyond what has been targeted by the instrumentation.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1f90379455699cf0ad09159c11a12dcd53070f6a
Mathieu Desnoyers [Wed, 28 Sep 2022 14:41:08 +0000 (10:41 -0400)]
Fix: event notification capture: validate buffer length
Validate that the buffer length is large enough to hold empty capture
fields.
If the buffer is initially not large enough to hold empty capture fields
for each field to capture, discard the notification.
If after capturing a field there is not enough room anymore in the
buffer to write empty capture fields, skip the offending large field by
writing an empty capture field in its place.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I819f2b3cdd7f23cd97e35ec5e5f615ef7d740dc5
Mathieu Desnoyers [Tue, 27 Sep 2022 20:14:26 +0000 (16:14 -0400)]
Fix: event notification capture error handling
When the captured fields end up taking more than
PIPE_BUF - sizeof(struct lttng_ust_abi_event_notifier_notification) - 1
bytes of space for the msgpack message, the notification append capture
fails.
Currently, the result is that the msgpack buffer will contain a (likely
corrupted) truncated msgpack data.
Handle those overflow errors, and when they are encountered, reset the
msgpack writer position to skip the problematic captured field entirely.
Change-Id: I7ba1bf06aa72512fc73211a1d8ae6823d0e8d7ff
Jérémie Galarneau [Wed, 14 Sep 2022 12:37:35 +0000 (13:37 +0100)] 
Fix: lttng-ust-comm: wait on wrong child process
The code currently assumes that the forked process is the only child
process at that point in time. However, there can be unreaped child
processes as reported in the original bug.
From wait(3), as currently used, "status is requested for any child
process."
Using the pid explicitly ensures a wait on the expected child process.
More context is available at:
https://bugs.lttng.org/issues/1359
Fixes #1359
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I8a4621d79c61f7dfefde5c2b94bdee9752e1973d
Michael Jeanson [Thu, 7 Jul 2022 21:01:54 +0000 (17:01 -0400)]
fix: 'make dist' without javah
Don't use 'BUILT_SOURCES' for the header file generated by javah /
javac, files added to this target will be generated on 'make dist'
regardless of the configuration or presence of the required tools.
Add proper make dependencies between the different targets instead of
using 'all-local'.
Set JAVAROOT to a temporary directory to properly clean class files and
avoid confusing javah when it's used to generate the JNI header.
Change-Id: I8544d0418039ba667d062cb01c924368ab702ab7
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 19 Aug 2022 20:24:00 +0000 (16:24 -0400)]
Version 2.13.4
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I718eb839ca2a8eb26196d1ed8fcdbf57348e1e71
Michael Jeanson [Mon, 1 Aug 2022 17:44:08 +0000 (13:44 -0400)]
cleanup: remove stale comment
Change-Id: I339fe13ff2d124fbf0a91223c090921902cb965d
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Wed, 17 Aug 2022 19:10:58 +0000 (15:10 -0400)]
Fix: disable array/sequence compile-time type check in C
Disable this compile-time check in C. Indeed, the C implementation of
lttng_ust_is_pointer_type does not support opaque pointer types, because
it relies on pointer arithmetic.
Therefore, remove this check to keep supporting opaque pointers as
array/sequence elements in probe providers.
The worse that could happen is that users providing an unsupported
type as array/sequence element will end up with a meaningless integer
field.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I0fa170f7af7fc016027685e48076ebaf0366cc5b
Michael Jeanson [Fri, 29 Jul 2022 15:12:57 +0000 (11:12 -0400)]
fix: add missing closedir in _get_max_cpuid_from_sysfs()
As reported by Coverity:
*** CID
1490849: (RESOURCE_LEAK)
/src/common/smp.c: 84 in _get_max_cpuid_from_sysfs()
78 * CPU num of 0.
79 */
80 if (max_cpuid < 0 || max_cpuid > INT_MAX)
81 max_cpuid = -1;
82
83 end:
>>> CID
1490849: (RESOURCE_LEAK)
>>> Variable "cpudir" going out of scope leaks the storage it points to.
84 return max_cpuid;
85 }
86
87 /*
88 * As a fallback to parsing the CPU mask in "/sys/devices/system/cpu/possible",
89 * iterate on all the folders in "/sys/devices/system/cpu" that start with
Change-Id: I2048e2473d66aaa2a275fe2923da84a7e105f235
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Thu, 28 Jul 2022 14:17:48 +0000 (10:17 -0400)]
Add more unit tests for possible_cpus_array_len
Change-Id: If0b7fb9183936f00ac90349fb32f1db57f124602
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 27 Jul 2022 18:23:41 +0000 (14:23 -0400)]
Clarify terminology around cpu ids and array length
Rename 'num_possible_cpus' to 'possible_cpus_array_len' to make it
clearer that we use this value to create arrays of per-CPU elements.
Change-Id: Ie5dc9293a95bf321f8add7e9c44ac677bc1fe539
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 27 Jul 2022 20:19:35 +0000 (16:19 -0400)]
fix: Unify possible CPU number fallback
The MUSL specific fallback to get the number of possible CPUs in the
system has the same issue with hot-unplugged CPUs as the Glibc
implementation we worked around by using the possible CPU mask from
sysfs.
To address this, unify our fallback code across all C libraries to get
the maximum CPU id from the directories in "/sys/devices/system/cpu".
Change-Id: I5541742dc1de8e011a942880825fa88c656f0905
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 27 Jul 2022 14:54:53 +0000 (10:54 -0400)]
fix: removed accidental VLA in _get_num_possible_cpus()
The LTTNG_UST_PAGE_SIZE define can either point to a literal value or
the sysconf() function making buf[] a VLA. Replace this by a
cpumask specifc define that will always be a literal value.
Change-Id: I8d329f314878e8018939f979861918969e3ec8ac
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 25 Jul 2022 19:53:17 +0000 (15:53 -0400)]
Fix: file descriptor leak in get_possible_cpu_mask_from_sysfs
Found by Coverity:
*** CID
1490808: Resource leaks (RESOURCE_LEAK)
/src/common/smp.c: 125 in get_possible_cpu_mask_from_sysfs()
119 max_bytes - total_bytes_read);
120
121 if (bytes_read < 0) {
122 if (errno == EINTR) {
123 continue; /* retry operation */
124 } else {
>>> CID
1490808: Resource leaks (RESOURCE_LEAK)
>>> Handle variable "fd" going out of scope leaks the handle.
125 return -1;
126 }
127 }
128
129 total_bytes_read += bytes_read;
130 assert(total_bytes_read <= max_bytes);
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I372b1fa2d454eeaa6462fe9c13692983369bea6b
Michael Jeanson [Wed, 20 Jul 2022 19:02:41 +0000 (15:02 -0400)]
Add unit tests for num possible cpus
Change-Id: I90eff0090b28cef64a8f4a5bd9745971ed89c711
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 20 Jul 2022 18:49:56 +0000 (14:49 -0400)]
fix: num_possible_cpus() with hot-unplugged CPUs
We rely on sysconf(_SC_NPROCESSORS_CONF) to get the maximum possible
number of CPUs that can be attached to the system for the lifetime of an
application. We use this value to allocate an array of per-CPU buffers
that is indexed by the numerical id of the CPUs.
As such we expect that the highest possible CPU id would be one less
than the number returned by sysconf(_SC_NPROCESSORS_CONF) which is
unfortunatly not always the case and can vary across libc
implementations and versions.
Glibc up to 2.35 will count the number of "cpuX" directories in
"/sys/devices/system/cpu" which doesn't include CPUS that were
hot-unplugged.
This information is however provided by the kernel in
"/sys/devices/system/cpu/possible" in the form of a mask listing all the
CPUs that could possibly be hot-plugged in the system.
This patch changes the implementation of num_possible_cpus() to first
try parsing the possible CPU mask to extract the highest possible value
and if this fails fallback to the previous behavior.
Change-Id: I1a3cb1a446154ec443a391d6689cb7d4165726fd
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Thu, 21 Jul 2022 13:10:30 +0000 (09:10 -0400)]
fix: Disable warnings for GNU extensions on Clang
Some versions of Clang enabled '-Wgnu' in '-Wall', since we rely on
GNUisms in the code this results in numerous errors. Check if the
compiler accepts '-Wno-gnu' to disable those warnings.
Change-Id: I9d1126744e427a6cf7c18e219cae5431227a43c0
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Thu, 21 Jul 2022 15:51:11 +0000 (11:51 -0400)]
fix: clang warning '-Wnull-pointer-subtraction' in lttng_ust_is_pointer_type
Some versions of Clang enable '-Wnull-pointer-subtraction' in '-Wall'
which results in the following message:
././ust-utils-common.h:166:2: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
ok_is_pointer_type(void *);
^~~~~~~~~~~~~~~~~~~~~~~~~~
././ust-utils-common.h:120:5: note: expanded from macro 'ok_is_pointer_type'
ok(lttng_ust_is_pointer_type(_type) == true, "lttng_ust_is_pointer_type - '" lttng_ust_stringify(_type) "' is a pointer")
~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../include/lttng/ust-utils.h:71:45: note: expanded from macro 'lttng_ust_is_pointer_type'
(lttng_ust_is_integer_type(typeof(((type)0 - (type)0))) && !lttng_ust_is_integer_type(type))
^
Since this macro is used only the determine if the type is a pointer we
can use any value other than NULL and thus not depend on undefined
behavior.
Change-Id: Iab7a182f580ce7431a817ab006ecdf3f1da09ae0
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
takeshi.iwanari [Fri, 24 Jun 2022 13:17:39 +0000 (22:17 +0900)] 
Fix: Use negative value for error code of lttng_ust_ctl_duplicate_ust_object_data
[As is]
- `lttng_ust_ctl_duplicate_ust_object_data` function is called by the following functions:
- `event_notifier_error_accounting_register_app` (lttng-tools)
- `duplicate_stream_object` (lttng-tools)
- `duplicate_channel_object` (lttng-tools)
- `lttng_ust_ctl_duplicate_ust_object_data` function returns positive value (= errno ＝ 24 = EMFILE) when system call `dup` returns error
- However, `duplicate_stream_object` and `duplicate_channel_object` functions expect negative value as error code
- As a result, these functions cannot handle error and segmentation fault occurs when using `stream->handle`
[Proposal]
- Currently, `lttng_ust_ctl_duplicate_ust_object_data` function returns either positive or negative value when error happens
- It looks convention is using negative value for error code (e.g. `-ENOMEM` )
- So, I propose to change `errno` to `-errno`
Signed-off-by: takeshi.iwanari <takeshi.iwanari@tier4.jp>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Iccb01930413ecd5a8c58ad267e9c4eca53694dc7
Mathieu Desnoyers [Thu, 23 Jun 2022 19:58:04 +0000 (15:58 -0400)]
Fix: sessiond wait futex: handle spurious futex wakeups
Observed issue
==============
LTTng-UST scheme for letting listener threads wait on session daemon
to wake up a futex is similar to the liburcu workqueue code, which has
an issue with spurious wakeups.
This wait/wakeup scheme is only used after the LTTng-UST listener thread
has been unable to connect to the session daemon.
A spurious wakeup on wait_for_sessiond can cause wait_for_sessiond to
return with a sock_info->wait_shm_mmap state of 0, which is unexpected.
However, this should not cause any user-observable issues other than
using slightly more CPU time than strictly needed, because this spurious
wakeup will only cause an additional connection attempt to the session
daemon to fail.
Cause
=====
From futex(5):
FUTEX_WAIT
Returns 0 if the caller was woken up. Note that a wake-up can
also be caused by common futex usage patterns in unrelated code
that happened to have previously used the futex word's memory
location (e.g., typical futex-based implementations of Pthreads
mutexes can cause this under some conditions). Therefore, call‐
ers should always conservatively assume that a return value of 0
can mean a spurious wake-up, and use the futex word's value
(i.e., the user-space synchronization scheme) to decide whether
to continue to block or not.
Solution
========
We therefore need to validate whether the value differs from 0 in
user-space after the call to FUTEX_WAIT returns 0.
Known drawbacks
===============
None.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I468d8ff302f467ee9924e6edb04476fcb031b4b9
Mathieu Desnoyers [Fri, 3 Jun 2022 19:55:16 +0000 (15:55 -0400)]
Version 2.13.3
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Icddeb085caf13e2045462bd1f7a2d71fda22fe67
Mathieu Desnoyers [Wed, 6 Apr 2022 15:16:06 +0000 (11:16 -0400)]
Document ust lock async-signal-safety
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ie150d5757cc050b0262dcea20f20c1da4963a27e
Mathieu Desnoyers [Wed, 6 Apr 2022 14:55:11 +0000 (10:55 -0400)]
Fix: don't use strerror() from ust lock nocheck
ust_lock_nocheck is meant to be async-signal-safe for use from the
fork() override helper (and fork(2) is async-signal-safe).
Remove calls to strerror() from ust lock functions and from the
cancelstate helper because strerror is not async-signal-safe and indeed
allocates memory.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I461f3631a24e71232d987b0a984b4942903bf9ac
Mathieu Desnoyers [Wed, 6 Apr 2022 14:17:15 +0000 (10:17 -0400)]
Fix: remove non-async-signal-safe fflush from ERR()
Commit
ff1fedb9f2e8 ("usterr: make error reporting functions signal safe")
changed the logging printout mechanism to use patient_write() to a file
descriptor to ensure signal-safety of the ERR() logging mechanism.
However, the fflush(stderr) was left in place, although it was useless.
Unfortunately, fflush() is not async-signal-safe.
Fix this by removing this fflush() call.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I13754acd914c4a9f71014a1e332c3fb25197a669
Mathieu Desnoyers [Fri, 20 May 2022 16:00:08 +0000 (12:00 -0400)]
Fix: Pointers are rejected by integer element compile time assertion for array and sequence
commit
2df82195d140b ("Add compile time assertion that array and
sequence have integer elements") introduced a check to validate that
sequences and arrays only contain integers. This was meant to refuse
arrays of double/float which are not supported.
However, as a side-effect, this also refuses arrays and sequences of
pointers, which were accepted prior to lttng-ust 2.13.
Introduce a lttng_ust_is_pointer_type() and use it in the array/sequence
type validation. The trick here is to use the fact that a difference
between two pointers in C is an integer. Therefore, we can validate that
an argument type is a pointer similarly to C++ is_pointer.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fixes: #1355
Change-Id: I7c96d24ab68fb711f85eccdb781a3c513b45c5dc
Jonathan Rajotte [Tue, 17 May 2022 18:09:42 +0000 (14:09 -0400)] 
Fix: statedump: invalid read during iter_end
Scenario
=========
Using a modified doc/examples/easy-ust/sample.c and dummy shared objects:
int main(int argc, char **argv)
{
int i = 0;
void *handle_cat;
void *handle_dog;
void (*func_print_name_cat)(const char*);
void (*func_print_name_dog)(const char*);
handle_dog = dlopen("./libdog.so", RTLD_NOW);
handle_cat = dlopen("./libcat.so", RTLD_NOW);
*(void**)(&func_print_name_dog) = dlsym(handle_dog, "print_name");
*(void**)(&func_print_name_cat) = dlsym(handle_cat, "print_name");
for (i = 0; i < 5; i++) {
tracepoint(sample_component, message, "Hello World");
usleep(1);
}
printf("Run `lttng regenerate statedump. Press enter \n");
getchar();
dlclose(handle_dog);
printf("Run `lttng regenerate statedump. Press enter \n");
getchar();
dlclose(handle_cat);
return 0;
}
On lttng side:
lttng create
lttng enable-event -u -a
lttng start
valgrind sample
Issue `lttng regenerate statedump` as the app suggest.
The second `lttng regenerate statedump` results in:
==934747== Invalid read of size 8
==934747== at 0x48BA90F: iter_end (lttng-ust-statedump.c:439)
==934747== by 0x48BAD73: lttng_ust_dl_update (lttng-ust-statedump.c:586)
==934747== by 0x48BADC0: do_baddr_statedump (lttng-ust-statedump.c:599)
==934747== by 0x48BAE62: do_lttng_ust_statedump (lttng-ust-statedump.c:633)
==934747== by 0x489F820: lttng_handle_pending_statedump (lttng-events.c:969)
==934747== by 0x488C000: handle_pending_statedump (lttng-ust-comm.c:717)
==934747== by 0x488DCF7: handle_message (lttng-ust-comm.c:1110)
==934747== by 0x48905EA: ust_listener_thread (lttng-ust-comm.c:1756)
==934747== by 0x4B62608: start_thread (pthread_create.c:477)
==934747== by 0x4A4D162: clone (clone.S:95)
==934747== Address 0x4c4ea88 is 4,152 bytes inside a block of size 4,176 free'd
==934747== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==934747== by 0x48B9588: free_dl_node (lttng-ust-statedump.c:123)
==934747== by 0x48BA90A: iter_end (lttng-ust-statedump.c:450)
==934747== by 0x48BAD73: lttng_ust_dl_update (lttng-ust-statedump.c:586)
==934747== by 0x48BADC0: do_baddr_statedump (lttng-ust-statedump.c:599)
==934747== by 0x48BAE62: do_lttng_ust_statedump (lttng-ust-statedump.c:633)
==934747== by 0x489F820: lttng_handle_pending_statedump (lttng-events.c:969)
==934747== by 0x488C000: handle_pending_statedump (lttng-ust-comm.c:717)
==934747== by 0x488DCF7: handle_message (lttng-ust-comm.c:1110)
==934747== by 0x48905EA: ust_listener_thread (lttng-ust-comm.c:1756)
==934747== by 0x4B62608: start_thread (pthread_create.c:477)
==934747== by 0x4A4D162: clone (clone.S:95)
==934747== Block was alloc'd at
==934747== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==934747== by 0x48B936A: zmalloc (helper.h:27)
==934747== by 0x48B936A: alloc_dl_node (lttng-ust-statedump.c:85)
==934747== by 0x48B98F7: find_or_create_dl_node (lttng-ust-statedump.c:184)
==934747== by 0x48BA205: extract_baddr (lttng-ust-statedump.c:339)
==934747== by 0x48BABC6: extract_bin_info_events (lttng-ust-statedump.c:528)
==934747== by 0x4A8D2F4: dl_iterate_phdr (dl-iteratephdr.c:75)
==934747== by 0x48BAD4C: lttng_ust_dl_update (lttng-ust-statedump.c:583)
==934747== by 0x48BADC0: do_baddr_statedump (lttng-ust-statedump.c:599)
==934747== by 0x48BAE62: do_lttng_ust_statedump (lttng-ust-statedump.c:633)
==934747== by 0x489F820: lttng_handle_pending_statedump (lttng-events.c:969)
==934747== by 0x488C000: handle_pending_statedump (lttng-ust-comm.c:717)
==934747== by 0x488DCF7: handle_message (lttng-ust-comm.c:1110)
==934747==
Cause
=========
Nodes can be removed during the `cds_hlist_for_each_entry_2` iteration which
is not meant to be used when items are removed within the traversal.
Solution
=========
Use `cds_hlist_for_each_entry_safe_2`.
Change-Id: Ibf3d94a4d6f7abac19ed9740eeacfbcb1bdf1f4f
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Wed, 30 Mar 2022 16:10:53 +0000 (12:10 -0400)]
Fix: bytecode interpreter context_get_index() leaves byte order uninitialized
Observed Issue
==============
When using the event notification capture feature to capture a context
field, e.g. '$ctx.cpu_id', the captured value is often observed in
reverse byte order.
Cause
=====
Within the bytecode interpreter, context_get_index() leaves the "rev_bo"
field uninitialized in the top of stack.
This only affects the event notification capture bytecode because the
BYTECODE_OP_GET_SYMBOL bytecode instruction (as of lttng-tools 2.13)
is only generated for capture bytecode in lttng-tools. Therefore, only
capture bytecode targeting contexts are affected by this issue. The
reason why lttng-tools uses the "legacy" bytecode instruction to get
context (BYTECODE_OP_GET_CONTEXT_REF) for the filter bytecode is to
preserve backward compatibility of filtering when interacting with
applications linked against LTTng-UST 2.12.
Solution
========
Initialize the rev_bo field based on the context field type
reserve_byte_order field.
Known drawbacks
===============
None.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I74996d501cee3c269658d98dfc0d0050b74c5ddb
Mathieu Desnoyers [Fri, 25 Mar 2022 17:44:49 +0000 (13:44 -0400)]
Version 2.13.2
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I09abe36e9e48fd4d676bc4904cf6d5b6ce18f1b6
Michael Jeanson [Thu, 17 Mar 2022 17:45:51 +0000 (13:45 -0400)]
fix: __STDC_VERSION__ can be undefined in C++
Caught on SLES12 with g++ 4.8 when enabling '-Wundef'.
Change-Id: Ib027f224a4f0ef021beb1709d8a626db62fe6d9c
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Wed, 9 Mar 2022 21:42:15 +0000 (16:42 -0500)]
Fix: sample discarded events count before reserve
Sampling the discarded events count in the buffer_end callback is done
out of order, and may therefore include increments performed by following
events (in following packets) if the thread doing the end-of-packet
event write is preempted for a long time.
Sampling the event discarded counts before reserving space for the last
event in a packet, and keeping this as part of the private ring buffer
context, should fix this race.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib59b634bbaefd2444751547d20a891c9dd93cd73
Mathieu Desnoyers [Thu, 10 Mar 2022 14:58:37 +0000 (09:58 -0500)]
Fix: ring buffer event counter
When compiling with -DLTTNG_RING_BUFFER_COUNT_EVENTS, the lttng-ust
libringbuffer can count events (with additional overhead). This is never
used or enabled by default. Fix this code so it compiles again when the
define is enabled.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I3aeeff7995d66a07316cc5c535b5271536a89636
Mathieu Desnoyers [Wed, 9 Mar 2022 16:54:33 +0000 (11:54 -0500)]
Fix: concurrent exec(2) file descriptor leak
If exec(2) is executed by the application concurrently with LTTng-UST
listener threads between the creation of a file descriptor with
socket(2), recvmsg(2), or pipe(2) and call to fcntl(3) FD_CLOEXEC, those
file descriptors will stay open after the exec, which is not intended.
As a consequence, shared memory files for ring buffers can stay present
on the file system for long-running traced processes.
Use:
- pipe2(2) O_CLOEXEC (supported since Linux 2.6.27, and by FreeBSD),
- socket(2) SOCK_CLOEXEC (supported since Linux 2.6.27, and by FreeBSD),
- recvmsg(2) MSG_CMSG_CLOEXEC (supported since Linux 2.6.23 and by FreeBSD),
rather than fcntl(2) FD_CLOEXEC to make sure the file descriptors are
closed on exec immediately upon their creation.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Id2167cf99d7cb8a8425fc0dc13745f023a504562
Michael Jeanson [Thu, 10 Feb 2022 15:25:02 +0000 (15:25 +0000)]
Add 'domain' parameter to the Log4j 2.x agent
The initial Log4j 2.x agent commit only implemented a compatibility mode
to be used with the existing LOG4J domain in lttng-tools.
In this mode the agent converts the new Log4j 2.x loglevel values to
their corresponding Log4j 1.x values in the same way the upstream
compatibility bridge does.
This is great when doing in-place migration using the upstream
compatibility bridge but doesn't cover the usecase of an application
that natively uses Log4j 2.x.
This commit adds a new mandatory 'domain' parameter to the Log4j2 agent
which currently only implements the 'LOG4J' compatibility domain in
preparation to adding a 'LOG4J2' domain.
The configuration for a single appender in Log4j 1.x compat mode will
now look like this:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
<Lttng name="LTTNG" domain="LOG4J"/>
</Appenders>
<Loggers>
<Root level="all">
<AppenderRef ref="LTTNG"/>
</Root>
</Loggers>
</Configuration>
Change-Id: I7fd5f79ad58c77175714bd4198d8ff5db2e6b846
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 2 Feb 2022 19:04:50 +0000 (19:04 +0000)]
fix: Convert custom loglevels in Log4j 2.x agent
The loglevel integer representation has changed between log4j 1.x and
2.x, we currently convert the standard loglevels but passthrough the
custom ones.
This can be problematic when using severity ranges as custom loglevels
won't be properly filtered.
Use the same strategy as the upstream Log4j 2.x compatibility layer by
converting the custom loglevels to their equivalent standard loglevel
value.
Change-Id: I8cbd4706cb774e334380050cf0b407e19d7bc7c4
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Fri, 28 Jan 2022 18:58:12 +0000 (18:58 +0000)]
fix: coverity reported null returns in Log4j2 agent
According to the log4j javadoc, these methods should not return null but
since it's reported by Coverity, add the null checks.
*** CID
1469124: Null pointer dereferences (NULL_RETURNS)
src/lib/lttng-ust-java-agent/java/lttng-ust-agent-log4j2/org/lttng/ust/agent/log4j2/LttngLogAppender.java:
194 in org.lttng.ust.agent.log4j2.LttngLogAppender.append(org.apache.logging.log4j.core.LogEvent)()
*** CID
1469123: Null pointer dereferences (NULL_RETURNS)
src/lib/lttng-ust-java-agent/java/lttng-ust-agent-log4j2/org/lttng/ust/agent/log4j2/LttngLogAppender.java:
167 in org.lttng.ust.agent.log4j2.LttngLogAppender.append(org.apache.logging.log4j.core.LogEvent)()
Change-Id: Ib992b3cc6848492cfb6e7d8fec6ce3898d962db4
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Thu, 6 Jan 2022 19:36:46 +0000 (14:36 -0500)]
Add a Log4j 2.x Java agent
This adds a new agent to the LTTng-UST Java agents suite supporting the
Log4j 2.x logging backend.
This new agent can be enabled with the following configure option :
$ export CLASSPATH=/path/to/log4j-core.jar:/path/to/log4j-api.jar
$ ./configure --enable-java-agent-log4j2
This backport differs from the master branch for the
'--enable-java-agent-all' option won't select this new agent since we
wanted to avoid introducing a new dependency in existing configurations.
The name of the new agent jar file is "lttng-ust-agent-log4j2.jar".
It will be installed in the arch-agnostic "$prefix/share/java" path
e.g: "/usr/share/java".
It uses the same jni library "liblttng-ust-log4j-jni.so" as the Log4j 1.x agent.
The agent was designed as a mostly drop-in replacement for applications
upgrading from Log4j 1.x to 2.x. It requires no modification to the
tracing configuration as it uses the same domain "-l / LOG4J" and the
loglevels integer representations are converted to the Log4j 1.x values
(excluding custom loglevels).
The recommended way to use this agent with Log4j 2.x is to add an
"Lttng" Appender with an arbiraty name and associate it with one or more
Logger using an AppenderRef.
For example, here is a basic log4j2 xml configuration that would send
all logging statements exlusively to an lttng appender:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
<Lttng name="LTTNG"/>
</Appenders>
<Loggers>
<Root level="all">
<AppenderRef ref="LTTNG"/>
</Root>
</Loggers>
</Configuration>
More examples can be found in the 'doc/examples' directory.
The implementation of the appender is based on this[1] great guide by
Keith D. Gregory which is so much more detailed than the official
documentation, my thanks to him.
[1] https://www.kdgregory.com/index.php?page=logging.log4j2Plugins
Change-Id: I34593c9a4c3140c8839cef8b58cc85745fe9f47f
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 18 Jan 2022 19:14:33 +0000 (19:14 +0000)]
Fix: may be used uninitialized on powerpc
Fix the following warning on powerpc :
In file included from ../../src/common/counter/counter-internal.h:16,
from ../../src/common/counter/counter-api.h:16,
from counter-clients/percpu-64-modular.c:12:
In function ‘__lttng_counter_add_percpu’,
inlined from ‘lttng_counter_add’ at ../../src/common/counter/counter-api.h:265:10,
inlined from ‘counter_add’ at counter-clients/percpu-64-modular.c:53:9:
include/urcu/compiler.h:25:42: warning: ‘move_sum’ may be used uninitialized [-Wmaybe-uninitialized]
25 | #define caa_unlikely(x) __builtin_expect(!!(x), 0)
| ^~~~~
../../src/common/counter/counter-api.h:244:13: note: in expansion of macro ‘caa_unlikely’
244 | if (caa_unlikely(move_sum))
| ^~~~~~~~~~~~
In file included from counter-clients/percpu-64-modular.c:12:
counter-clients/percpu-64-modular.c: In function ‘counter_add’:
../../src/common/counter/counter-api.h:237:17: note: ‘move_sum’ declared here
237 | int64_t move_sum;
| ^~~~~~~~
Change-Id: I65dc61a567c0337735124a35f1af96697d416054
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Wed, 26 Jan 2022 15:54:55 +0000 (10:54 -0500)]
Revert "Fix: ustcomm: serialize variant_nestable type"
lttng-sessiond does not expect the variant_nestable type when generating
UST metadata. This fix only belongs to the master branch, not to a
stable branch.
This reverts commit
0b7bf25dd97168c3410e5601280637c0f64928ef.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I0f000b01b7bf24eadd3cea9480d84065a0a72c26
Mathieu Desnoyers [Tue, 25 Jan 2022 02:08:35 +0000 (21:08 -0500)]
Fix: ustcomm: serialize variant_nestable type
LTTng-UST 2.13 serializes the contents of the variant_nestable union
field, but keeps the "atype" as lttng_ust_ctl_atype_variant.
It happens to work by pure chance because the binary layout of the
variant_nestable and legacy.variant union fields are the same, except
for the alignment field of variant_nestable which is zeroed padding in
the legacy.variant. Therefore, as long as the variant_nestable has a
padding of 0, everything works out fine (which is currently the case).
But it's better to fix this discrepancy in case we ever plan to use a
nonzero variant alignment.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I96a3e1f6bfbe410ed61ea59313eb49b6c4f4b40d
Mathieu Desnoyers [Tue, 18 Jan 2022 15:37:56 +0000 (10:37 -0500)]
Fix: doc/examples/java-log4j: fix paths to directories
Since the directory hierarchy refactoring introduced in the 2.13 release
of lttng-ust, the paths in `run` are wrong, they are missing a `src`
component.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ibfcf8ac7f85049432f4788a5134e06eb5fe2434e
Simon Marchi [Fri, 7 Jan 2022 16:31:58 +0000 (11:31 -0500)] 
Fix: doc/examples/java-jul: fix paths to directories
I tried to run this example, but got:
$ ./run
Error: Unable to initialize main class Hello
Caused by: java.lang.NoClassDefFoundError: org/lttng/ust/agent/jul/LttngLogHandler
The paths in `run` are wrong, they are missing a `src` component. Fix
that.
Change-Id: I63f4532c5ec1d989f66b7061a154986692e2edf9
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 14 Jan 2022 19:59:43 +0000 (14:59 -0500)]
Copyright ownership transfer
Apply copyright ownership transfer from David Goulet and Julien Desfossez
to EfficiOS Inc.
Link: https://lists.lttng.org/pipermail/lttng-dev/2022-January/030087.html
Link: https://lists.lttng.org/pipermail/lttng-dev/2022-January/030092.html
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: David Goulet <dgoulet@ev0ke.net>
Cc: Julien Desfossez <ju@klipix.org>
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Signed-off-by: Julien Desfossez <ju@klipix.org>
Change-Id: Ibc6bb52296406e68466d44ae991a7ab70134dd76
Mathieu Desnoyers [Fri, 10 Dec 2021 20:36:53 +0000 (15:36 -0500)]
Version 2.13.1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ic70dee2853d6a09e23ee32ecb46944d522276ddb
Mathieu Desnoyers [Thu, 9 Dec 2021 21:07:15 +0000 (16:07 -0500)]
Fix: ust-compiler: constructor/destructor build on g++ 4.8
g++ 4.8 build fails with:
15:16:07 ../../../../include/lttng/ust-compiler.h:104:31: error: can’t set ‘no_instrument_function’ attribute after definition
15:16:07 LTTNG_UST__TP_COMBINE_TOKENS(lttng_ust_constructor_destructor_, \
15:16:07 ^
15:16:07 ../../../../include/lttng/tracepoint.h:84:3: note: in definition of macro ‘LTTNG_UST___TP_COMBINE_TOKENS’
15:16:07 _tokena##_tokenb
15:16:07 ^
15:16:07 ../../../../include/lttng/ust-compiler.h:104:2: note: in expansion of macro ‘LTTNG_UST__TP_COMBINE_TOKENS’
15:16:07 LTTNG_UST__TP_COMBINE_TOKENS(lttng_ust_constructor_destructor_, \
15:16:07 ^
15:16:07 ../../../../include/lttng/ust-tracepoint-event.h:1230:1: note: in expansion of macro ‘LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR’
15:16:07 LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR(
15:16:07 ^
15:16:07 In file included from ../../../../include/lttng/tracepoint.h:25:0,
15:16:07 from ust_tests_hello.h:13,
15:16:07 from tp-cpp.cpp:8:
15:16:07 ../../../../include/lttng/ust-compiler.h:109:2: error: can’t set ‘no_instrument_function’ attribute after definition
15:16:07 ~LTTNG_UST__TP_COMBINE_TOKENS(lttng_ust_constructor_destructor_, \
15:16:07 ^
15:16:07 ../../../../include/lttng/ust-tracepoint-event.h:1230:1: note: in expansion of macro ‘LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR’
15:16:07 LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR(
15:16:07 ^
Fix this by moving the implementation of the constructor and destructor
outside of the class, thus applying the attribute to a forward
declaration.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I9e097d50dff7a8f9bef07b04ddad38bd6877f892
Mathieu Desnoyers [Thu, 9 Dec 2021 20:40:19 +0000 (15:40 -0500)]
ust-compiler: constructor/destructor whitespaces layout and macro dependency
Introduce LTTNG_UST_COMPILER_COMBINE_TOKENS in lttng/ust-compiler.h to
eliminate a circular dependency from ust-compiler.h to
LTTNG_UST__TP_COMBINE_TOKENS (defined in tracepoint.h). Use it in
LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR.
Change the layout of LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR to use
tabs rather than spaces.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I71ecac349a1425401df62eb600ee74f4f930da09
Mathieu Desnoyers [Thu, 9 Dec 2021 19:43:06 +0000 (14:43 -0500)]
Fix: ust-cancelstate: include string.h for strerror
strerror() is provided by string.h, not error.h. Also error.h is not
present on FreeBSD, which causes the build to fail.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Id5e29df184c1f24659e15bc16c73da01fc819905
Jonathan Rajotte [Tue, 9 Nov 2021 15:43:53 +0000 (10:43 -0500)]
Fix: libnuma is prepended to LIBS
The default behavior, for AC_CHECK_LIB when the `action-if-found` is NOT
defined, is to prepend the library to LIBS. [1]
"
If action-if-found is not specified, the default action prepends
-llibrary to LIBS and defines ‘HAVE_LIBlibrary’ (in all capitals).
"
It is important to note that the LIBS variable is used for ALL linking.
This is normally not a problem for most distribution since they force
the use of `--as-needed` at the toolchain level (gcc specs) (for example
debian [2]). One could also pass the `--as-needed` flag manually but
libtool reorganize flags in the case of shared object creation [3].
In our case, we always explicitly state the dependencies via the *_LIBADD
automake clause. We do not rely on the LIBS variable.
Simply force the define of HAVE_LIBNUMA to prevent the prepending to
LIBS.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Libraries.html
[2] https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/gcc-as-needed.diff
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I33221d14b96482ff71672458097423289f6b9fc2
Michael Jeanson [Thu, 2 Dec 2021 21:11:21 +0000 (16:11 -0500)]
fix: Allow disabling some abi compat tests
Allow disabling ABI compat tests that rely on a library using a symbol from
the global offset table even if it provides its own copy, which is the
default behavior on Linux.
This situation happens when using the '-Bsymbolic-functions' linker flag
which binds references to public symbols in a library to the definition
within the library, bypassing the global offset table.
To disable those tests when running the test suite, set the
UST_TESTS_LD_SYMBOLIC_FUNC environment variable to any value, for
example :
make check UST_TESTS_LD_SYMBOLIC_FUNC=1
Change-Id: I1ed23d90bbe1b174ab7b4fccfb40b701b291c074
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jérémie Galarneau [Mon, 6 Dec 2021 21:51:48 +0000 (16:51 -0500)]
Fix: generate probe registration constructor as a C++ constuctor
Observed issue
==============
Applications which transitively dlopen() a library which, in turn,
dlopen() providers crash when they are compiled with clang or
if LTTNG_UST_ALLOCATE_COMPOUND_LITERAL_ON_HEAP is defined.
Core was generated by `././myapp.exe'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fa94f860bc2 in check_event_provider (probe_desc=<optimized out>) at lttng-probes.c:153
153 if (!check_type_provider(field->type)) {
[Current thread is 1 (Thread 0x7fa94fcbc740 (LWP 511754))]
(gdb) bt
#0 0x00007fa94f860bc2 in check_event_provider (probe_desc=<optimized out>) at lttng-probes.c:153
#1 lttng_ust_probe_register (desc=0x7fa94fe9dc80 <lttng_ust__probe_desc___embedded_sys>)
at lttng-probes.c:242
#2 0x00007fa94fe9ba3c in lttng_ust__tracepoints__ptrs_destroy ()
at /usr/include/lttng/tracepoint.h:590
#3 0x00007fa94fedfe2e in call_init () from /lib64/ld-linux-x86-64.so.2
#4 0x00007fa94fedff1c in _dl_init () from /lib64/ld-linux-x86-64.so.2
#5 0x00007fa94fdf7d45 in _dl_catch_exception () from /usr/lib/libc.so.6
#6 0x00007fa94fee420a in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#7 0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/libc.so.6
#8 0x00007fa94fee39bb in _dl_open () from /lib64/ld-linux-x86-64.so.2
#9 0x00007fa94fe8d36c in ?? () from /usr/lib/libdl.so.2
#10 0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/libc.so.6
#11 0x00007fa94fdf7db3 in _dl_catch_error () from /usr/lib/libc.so.6
#12 0x00007fa94fe8db99 in ?? () from /usr/lib/libdl.so.2
#13 0x00007fa94fe8d3f8 in dlopen () from /usr/lib/libdl.so.2
#14 0x00007fa94fecc647 in mon_constructeur () at mylib.cpp:20
#15 0x00007fa94fedfe2e in call_init () from /lib64/ld-linux-x86-64.so.2
#16 0x00007fa94fedff1c in _dl_init () from /lib64/ld-linux-x86-64.so.2
#17 0x00007fa94fdf7d45 in _dl_catch_exception () from /usr/lib/libc.so.6
#18 0x00007fa94fee420a in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#19 0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/libc.so.6
#20 0x00007fa94fee39bb in _dl_open () from /lib64/ld-linux-x86-64.so.2
#21 0x00007fa94fe8d36c in ?? () from /usr/lib/libdl.so.2
#22 0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/libc.so.6
#23 0x00007fa94fdf7db3 in _dl_catch_error () from /usr/lib/libc.so.6
#24 0x00007fa94fe8db99 in ?? () from /usr/lib/libdl.so.2
#25 0x00007fa94fe8d3f8 in dlopen () from /usr/lib/libdl.so.2
#26 0x00005594f478c18c in main ()
Cause
=====
Building tracepoint instrumentation as C++ using clang causes
LTTNG_UST_ALLOCATE_COMPOUND_LITERAL_ON_HEAP to be defined due to a
compiler version detection problem addressed by another patch.
However, building with LTTNG_UST_ALLOCATE_COMPOUND_LITERAL_ON_HEAP
defined still results in the crash.
When LTTNG_UST_ALLOCATE_COMPOUND_LITERAL_ON_HEAP is defined, the
lttng_ust_event_field lttng_ust__event_fields__[...] structure is
initialized by dynamically-allocating field structures for the various
fields.
As the initialization can't be performed statically, it is performed at
run-time _after_ the execution of the library constructors has
completed.
Moreover, the generated initialization
function of the provider (lttng_ust__events_init__[...]) is declared as being a library
constructor. Hence, this causes it to run before the
tracepoint fields structures has a chance to be initialized.
This all results in a NULL pointer dereference during the validation of
the fields.
Solution
========
When building providers as C++, the initialization function is defined
as the constructor of a class. This class is, in turn, instantiated in
an anonymous namespace.
For the purposes of this patch, the use of an anonymous namespace is
equivalent to declaring the instance as 'static', but it is preferred in
C++11.
Known drawbacks
===============
None.
References
==========
A reproducer is available:
https://github.com/jgalar/ust-clang-reproducer
Problem initially reported on dotnet/runtime's issue tracker:
https://github.com/dotnet/runtime/issues/62398
Relevant LTTng-UST issue:
https://bugs.lttng.org/issues/1339
Fixes: #1339
Change-Id: I51cfbe74729bd45e2613a30bc8de17e08ea8233d
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Thu, 9 Sep 2021 16:49:26 +0000 (12:49 -0400)]
Fix: nestable pthread cancelstate
The pthread cancelstate disable performed to ensure threads are not
cancelled while holding mutexes which are used in library destructors
does not currently support that those mutexes may be nested. It
generates error messages when using the fork and fd helpers when running
with LTTNG_UST_DEBUG=1. The effect of this is that the pthread
cancelstate can be re-enabled too soon when the first unlock is
performed (in a nested lock scenario), thus allowing the thread to be
cancelled while still holding a lock, and causing a deadlock on
application exit.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ife8b1fee04c7d7c480e59bdfc158abdee771994c
Jonathan Rajotte [Mon, 6 Dec 2021 14:20:58 +0000 (09:20 -0500)]
Fix: abort on decrement_sem_count during concurrent tracing start and teardown
Observed issue
==============
The following backtrace has been reported:
#0 __GI_raise (sig=sig@entry=6)
at /usr/src/debug/glibc/2.31/git/sysdeps/unix/sysv/linux/raise.c:50
#1 0x0000007f90b3fdd4 in __GI_abort () at /usr/src/debug/glibc/2.31/git/stdlib/abort.c:79
#2 0x0000007f90b4bf50 in __assert_fail_base (fmt=0x7f90c3da98 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7f9112cb90 "uatomic_read(&sem_count) >= count",
file=file@entry=0x7f9112cb30 "/usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c",
line=line@entry=664, function=function@entry=0x7f911317e8 <__PRETTY_FUNCTION__.10404> "decrement_sem_count")
at /usr/src/debug/glibc/2.31/git/assert/assert.c:92
#3 0x0000007f90b4bfb4 in __GI___assert_fail (assertion=assertion@entry=0x7f9112cb90 "uatomic_read(&sem_count) >= count",
file=file@entry=0x7f9112cb30 "/usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c",
line=line@entry=664, function=function@entry=0x7f911317e8 <__PRETTY_FUNCTION__.10404> "decrement_sem_count")
at /usr/src/debug/glibc/2.31/git/assert/assert.c:101
#4 0x0000007f910e3830 in decrement_sem_count (count=<optimized out>)
at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:664
#5 0x0000007f910e5d28 in handle_pending_statedump (sock_info=0x7f9115c608 <global_apps>)
at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:737
#6 handle_message (lum=0x7f8dde46d8, sock=3, sock_info=0x7f9115c608 <global_apps>)
at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:1410
#7 ust_listener_thread (arg=0x7f9115c608 <global_apps>)
at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:2055
#8 0x0000007f90af73e0 in start_thread (arg=0x7fc27a82f6)
at /usr/src/debug/glibc/2.31/git/nptl/pthread_create.c:477
#9 0x0000007f90bead5c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
It turns out that the main thread is at that point iterating over the
libraries destructors:
Thread 3 (LWP 1983):
#0 0x0000007f92a68a0c in _dl_fixup (l=0x7f9054e510, reloc_arg=432)
at /usr/src/debug/glibc/2.31/git/elf/dl-runtime.c:69
#1 0x0000007f92a6ea3c in _dl_runtime_resolve () at ../sysdeps/aarch64/dl-trampoline.S:100
#2 0x0000007f905170f8 in __do_global_dtors_aux () from <....>/crash/work/rootfs/usr/lib/libbsd.so.0
#3 0x0000007f92a697f8 in _dl_fini () at /usr/src/debug/glibc/2.31/git/elf/dl-fini.c:138
#4 0x0000007f90b54864 in __run_exit_handlers (status=0, listp=0x7f90c65648 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
at /usr/src/debug/glibc/2.31/git/stdlib/exit.c:108
#5 0x0000007f90b549f4 in __GI_exit (status=<optimized out>)
at /usr/src/debug/glibc/2.31/git/stdlib/exit.c:139
#6 0x0000000000404c98 in a_function_name (....) at main.c:152
#7 0x0000000000404a98 in main (argc=3, argv=0x7fc27a8858, env=0x7fc27a8878) at main.c:97
Cause
=====
An enable command is processed at the same time that the lttng-ust
destructor is run. At the end of the command handling,
`handle_pending_statedump` is called. Multiple variables from the
`sock_info` struct are checked outside the UST lock at that point.
lttng-ust-comm.c +1406:
/*
* Performed delayed statedump operations outside of the UST
* lock. We need to take the dynamic loader lock before we take
* the UST lock internally within handle_pending_statedump().
*/
handle_pending_statedump(sock_info);
Namely:
registration_done
statedump_pending
initial_statedump_done
`statedump_pending` is set during the enable command
(`lttng_session_statedump`, lttng-events.c +631) in the same thread.
As for `registration_done` and `initial_statedump_done` they are invariant
from the registration of the app until `lttng_ust_cleanup` is called.
`cleanup_sock_info` called by `lttng_ust_cleanup`, itself called by
`lttng_ust_exit` resets the `registration_done` and
`initial_statedump_done` fields. Note that these operations are done
outside of the listener thread.
Note that by that point `lttng_ust_exit` expects all "getters" on
`sock_info` to fail while trying to acquire the UST lock due to
`lttng_ust_comm_should_quit` set to 1. Note that the listener threads
can still exist because we do not join them, we only execute
pthread_cancel which is async.
Clearly we are missing mutual exclusion provided by locking
when accessing `registration_done` and `initial_statedump_done`.
Solution
========
Here we can do better and simply not require any mutual exclusion based on locking.
`registration_done` and `initial_statedump_done` only need to be reset
to zero when we are not actually exiting (`lttng_ust_after_fork_child`).
In this case, no concurrent listener thread exists at that point
that could access those fields during the reset. Hence we can move the
reset to only the non-exiting code path and alleviate the current
situation.
Known drawbacks
===============
None.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I45ba3eaee20c49a3988837a87fa680ce0a6ed953
Michael Jeanson [Mon, 6 Dec 2021 20:05:59 +0000 (15:05 -0500)]
fix: allocating C++ compound literal on heap with Clang
Exclude Clang from the GCC version macro check for <= 4.8 since most
versions of Clang seem to identify themselves as GCC 4.2 which in this
case forces the allocation of C++ compound literals on the heap which
is only supported starting with Clang >= 6.0.
The macro was also broken for GCC <= 4.8 in C mode, add missing
parentheses around the 'or' statement to properly distinguish between C
and C++.
Also document the minimal supported version of Clang 4.0 to build C++
probe providers.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I62eea00381b7dc5958a09b13044ad9e7f7caf2ab
Michael Jeanson [Wed, 8 Dec 2021 20:54:53 +0000 (15:54 -0500)]
Check for C++11 when building C++ probe providers
The compiler used to build probe providers might differ from the one
used to build lttng-ust, make sure that when a probe provider is built
by a C++ compiler, it supports C++11.
Change-Id: I2a17e923316ff87c023d8e50c53efdbe35386a21
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 9 Mar 2021 17:38:06 +0000 (12:38 -0500)]
fix: liblttng-ust-fd async-signal-safe close()
"close(2)" is documented as async-signal-safe (see signal-safety(7)) and
as such our override function should also be. This means we shouldn't do
lazy initialization of the function pointer to the original libc close
symbol in the override function.
If we move the initialization of the function pointer in the library
constructor we risk breaking other constructors that may run before ours
and call close().
A compromise is to explicitly do the initialization in the constructor
but keep a lazy init scheme if close() is called before it is executed.
The dlsym call is now done only once, if it fails the wrappers will
return -1 and set errno to ENOSYS.
Change-Id: I05c66d2f5d51b2022c6803ca215340fb9c00f5a8
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 4 Oct 2021 20:44:57 +0000 (16:44 -0400)]
tracepoints: print debug message when lttng-ust-tracepoint.so is not found
Rather than silently disable tracepoints when lttng-ust-tracepoint.so is
not found in the library search path, print a debug message when either
the compile unit including tracepoint.h has defined LTTNG_UST_DEBUG, or
when the LTTNG_UST_DEBUG environment variable is set.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I909f9b8dcd0cbc5faae3789931883f1941973207
Mathieu Desnoyers [Thu, 25 Nov 2021 21:02:29 +0000 (16:02 -0500)]
Fix: static_assert unavailable with glibc < 2.16
gcc 4.8 introduces support for C11, and gcc 4.6 introduces support for
_Static_assert. Therefore, using _Static_assert when C11 is detected is
always OK.
However, using static_assert in C11 depends on glibc >= 2.16. Even
though the minimum version requirement for glibc is not documented in
the README.md file, make a best effort to keep compatibility with older
glibc.
Fixes: #1331
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I33b65b839ea5ecd0f710179a7ef6fb6f5fda2e17
Mathieu Desnoyers [Wed, 24 Nov 2021 19:13:28 +0000 (14:13 -0500)]
Fix: combined tracing of lttng-ust 2.12/2.13 generates corrupted traces
Observed issue
==============
When tracing applications linked against lttng-ust 2.12 and lttng-ust
2.13 in parallel with a lttng-tools 2.13 into the same per-uid buffers,
with the "procname" context enabled, babeltrace fails with "Event id NN
is outside range" when reading the trace:
[14:51:58.
717006865] (+5.
927872956) x lttng_ust_statedump:start: { cpu_id = 1 }, { procname = "sample-2.13-ust" }, { }
[error] Event id 41984 is outside range.
[error] Reading event failed.
Error printing trace.
Cause
=====
Inspection of the trace reveals that the layout of the procname context
field changed from 17 bytes to 16 bytes between 2.12 and 2.13. This is
an issue when applications share a per-uid ring buffer, because context
fields are associated with channels, and need to have the same layout
across all processes tracing into a given channel.
The layout of the procname field described by the trace metadata is that
of the first application which happens to register that channel in the
session lifetime.
Therefore, the procname context field length is part of the LTTng-UST
ABI and cannot be changed without breaking the LTTng-UST ABI (bumping
LTTNG_UST_ABI_MAJOR_VERSION_OLDEST_COMPATIBLE), which is unwanted
between 2.12 and 2.13. Keeping compatibility for combined use by
different applications between lttng-ust 2.12 and 2.13 is a required
feature for this release, because lttng-ust 2.13 introduces a library
ABI break (soname bump).
An example scenario leading to this issue:
1) trace created for per-uid buffers,
2) add procname context
3) start tracing
4) Application [a] linked against lttng-ust 2.13 registers the channel to
lttng-sessiond, sending its context descriptions with a 16-byte
procname context field,
5) Application [b] linked against lttng-ust 2.12 registers the same channel
to lttng-sessiond,
6) Application [b] traces an event with the procname context, followed
by an event payload with a single "string" field.
7) A trace viewer will observe the procname context, followed by an
extra null character, and thus mistakenly consider the event payload
to be an empty string. Reading the next event header will fail
because the string payload will be expected to contain an event ID.
Solution
========
Revert the procname context field size to 17 bytes to stay compatible
with lttng-ust 2.12.
In an abundance of caution, also revert the size of the
lttng_ust_statedump:procname "procname" field to 17, so there won't be
duplicated event IDs for this event when applications linked against
lttng-ust 2.12 and 2.13 are traced concurrently for the same user ID
in per-uid tracing.
History
=======
This issue was introduced by commit
0db3d6ee9be ("port: fix
pthread_setname_np integration") within the 2.13 development cycle.
Known drawbacks
===============
Applications currently running which are linked against a liblttng-ust
2.13 without this fix should be restarted after upgrading the library to
liblttng-ust 2.13 with this fix.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I206086df8b71463c248ca186343baaff5452762b
Michael Jeanson [Thu, 4 Nov 2021 16:14:59 +0000 (12:14 -0400)]
doc/man: Document LTTNG_UST_ABORT_ON_CRITICAL variable
This new environment variable was added in 2.13 but only documented in
the README file, add it to the man page.
Change-Id: Ic7dbafe5cf7d8870a78d793134c789c5f24e80c8
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Thu, 11 Nov 2021 21:38:14 +0000 (16:38 -0500)]
fix: remove autoconf features default value in help message
The default values of yes|no can be confusing combined with the
--enable / --disable switches of autoconf, remove them from the help
message.
Change-Id: I9a85d6d759372d3932c9a8d302d42a468f2e6520
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 10 Nov 2021 20:11:01 +0000 (15:11 -0500)]
Set git-review branch to stable-2.13
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I634150fed550a5bdf1cf3b9001a4d2a234ada4ac
Simon Marchi [Thu, 2 Sep 2021 02:30:02 +0000 (22:30 -0400)]
Fix: add extern "C" to two header files
These are needed to build some lttng-tools binary as C++ programs.
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Iba97d9cc52f86fd01cc24111c53a85340595e4c4
Mathieu Desnoyers [Mon, 2 Aug 2021 20:44:15 +0000 (16:44 -0400)]
Version 2.13.0
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ic4096213364251e43f99c677790fa29482d967da
Mathieu Desnoyers [Fri, 16 Jul 2021 18:01:30 +0000 (14:01 -0400)]
Version 2.13.0-rc3
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I9b5f6f6aa5860d9c0f91a1660854573649609fda
Mathieu Desnoyers [Fri, 28 May 2021 15:23:46 +0000 (11:23 -0400)]
Documentation: clarify API backward compatibility comment
Considering that the ABI (soname major version) and API version can
evolve independently in the future, remove references to the soname
major version from the API compatibility documentation.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ic632c3d0f0940a689139a8e1d19dc5766382327e
Philippe Proulx [Wed, 9 Jun 2021 19:39:25 +0000 (15:39 -0400)] 
doc/man: only mention `-llttng-ust-common` in synopses (conditionally)
LTTng-UST only requires that you link your application or tracepoint
provider package with `-llttng-ust-common` if you define
`_LGPL_SOURCE` before you include, directly or indirectly,
`<lttng/tracepoint.h>`.
The `_LGPL_SOURCE` definition is specific to the EfficiOS/LTTng
projects.
Because defining `_LGPL_SOURCE` is not considered the typical scenario,
remove instructions to link with `-llttng-ust-common` throughout the
manual pages, except in synopses, to make such instructions more
readable/light.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I460a2f746d5e2904660a11b3151d0d01776361db
Philippe Proulx [Wed, 9 Jun 2021 19:26:01 +0000 (15:26 -0400)]
doc/man: remove vtracef() and vtracelog() manual pages
Following
2268c76f ("Remove vtracelog and vtracef from v0 compat API"),
this patch removes the manual pages of vtracef() and vtracelog() which
don't exist.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1a07c74b330015ee74bb92235db2171066751503
Mathieu Desnoyers [Wed, 9 Jun 2021 15:38:08 +0000 (11:38 -0400)]
Remove vtracelog and vtracef from v0 compat API
vtracelog and vtracef were introduced between lttng-ust 2.12 and 2.13
(not released yet). They are replaced by lttng_ust_vtracelog and
lttng_ust_vtracef in the v1 API, newly introduced in lttng-ust 2.13.
Therefore, there is no need to expose a v0 compat API for the vtracelog
and vtracef macros which were never officially part of any release
other than the 2.13 release candidates.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I96cfed7d6c211d24017bfd33cd8d8c5a7087d78f
Michael Jeanson [Wed, 3 Mar 2021 16:56:49 +0000 (11:56 -0500)]
Add serialized ABI definition files
This commit contains the serialized ABI definitions for a typical build
of the lttng-ust librairies. This information is extracted using
libabigail (https://sourceware.org/libabigail/).
The artefacts used to generate these were built with CFLAGS="-O0 -ggdb"
and all optional configure switches enabled.
You can compare the serialized ABI with a shared object to check for
changes. For example, here we compare an in-tree built version of
liblttng-ust.so with the serialized ABI of stable-2.13 :
abidiff \
extras/abi/2.13/x86_64-pc-linux-gnu/liblttng-ust.so.1.xml \
src/lib/lttng-ust/.libs/liblttng-ust.so
Change-Id: Ie3b6fa78b156556bb9967bebab36c8e4f563bbe3
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Philippe Proulx [Tue, 25 May 2021 17:06:56 +0000 (13:06 -0400)]
doc/man: document LTTng-UST 2.13
Significant changes:
* Prefix all macro/definition names with `LTTNG_UST_` or `lttng_ust_`
where needed.
* Prefix all log level definitions with `LTTNG_UST_TRACEPOINT_LOGLEVEL`.
* lttng-ust(3):
* Add "Compatibility with previous APIs" section to explain
the new `LTTNG_UST_COMPAT_API_VERSION` definition.
* Document the new tracepoint class provider name parameter of
`LTTNG_UST_TRACEPOINT_EVENT_INSTANCE()`.
Update examples accordingly.
* Mention `liblttng-ust-common` where missing.
* tracef(3), vtracef(3), tracelog(3), and vtracelog(3) now indicate that
the macros are part of version 0 of the LTTng-UST API, albeit still
available, and point to lttng_ust_tracef(3), lttng_ust_vtracef(3),
lttng_ust_tracelog(3), and lttng_ust_vtracelog(3).
* New lttng_ust_do_tracepoint(3), lttng_ust_tracepoint(3),
and lttng_ust_tracepoint_enabled(3) manual pages which source
lttng-ust(3).
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I07d6ace0d6f219c36d7c99a455726bbf4b0736a2
Michael Jeanson [Tue, 27 Apr 2021 15:12:20 +0000 (11:12 -0400)]
doc: add -llttng-ust-common to linking cmd in manpages
Change-Id: I82de93db32dd35b044810801ceab9dd2816d7fbd
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 27 Apr 2021 15:00:41 +0000 (11:00 -0400)]
doc: xmlto output to stdout on a verbose build
When running 'make V=1' send the output of xmlto to stdout to help with
debugging command failures.
Change-Id: Ia974bb0ca9671129499b7966e8790a594ce034b2
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Thu, 27 May 2021 14:44:38 +0000 (10:44 -0400)]
Cleanup: remove useless lttng_ust_probe_supports_event_notifier
LTTng-UST 2.13 bumps the accepted probe provider major version to 3,
therefore we can remove the lttng_ust_probe_supports_event_notifier
version check, which requires that the probe provider major version is
>= 2, because it is now useless.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Id31581d2728f1197788ce4e7a79c6c494c444b08
Michael Jeanson [Mon, 17 May 2021 15:24:47 +0000 (11:24 -0400)]
fix: disable some abi conflict tests on FreeBSD
On FreeBSD, symbol resolution when dlopening a shared object will always
favor symbols local to this shared object and thus our canary function will
never be called which breaks our abi conflict detection when abi1 is loaded
first.
Disable the test cases with this scenario on FreeBSD as we have no way
to fix this at the moment.
Change-Id: Ic0451ce61e21f94ece55429b41bf76db3ad74b3a
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 17 May 2021 12:40:17 +0000 (08:40 -0400)]
Fix: handle leak in abi tests
Coverity finds that dlopen_ust leaks handles. Modify the code structure
to keep track of those handles in library descriptors so they are not
leaked.
*** CID
1453155: (RESOURCE_LEAK)
/tests/regression/abi0-conflict/app_ust_dlopen.c: 35 in dlopen_ust()
29 printf("Error: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
30 ret = EXIT_FAILURE;
31 } else {
32 printf("Success: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
33 }
34
>>> CID
1453155: (RESOURCE_LEAK)
>>> Variable "handle" going out of scope leaks the storage it points to.
35 return ret;
36 }
37
38 static
39 int dlopen_abi0(void)
40 {
/tests/regression/abi0-conflict/app_noust_dlopen.c: 31 in dlopen_ust()
25 printf("Error: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
26 ret = EXIT_FAILURE;
27 } else {
28 printf("Success: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
29 }
30
>>> CID
1453155: (RESOURCE_LEAK)
>>> Variable "handle" going out of scope leaks the storage it points to.
31 return ret;
32 }
33
34 static
35 int dlopen_abi0(void)
36 {
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I967c2e8741c6d42c0c12e19fbadc81e1c91d1e0f
Mathieu Desnoyers [Sat, 15 May 2021 01:31:26 +0000 (21:31 -0400)]
Version 2.13.0-rc2
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I2841cba86e1f93f82cc966a32e063928e949cea4
Jérémie Galarneau [Fri, 14 May 2021 23:13:32 +0000 (19:13 -0400)]
Fix: ustcomm: application name uses the '-ust'-suffixed thread name
During the 2.13 development cycle, the compatibility pthread_setname_np
compatibility layer was fixed (see
0db3d6ee). Unfortunately, this had a
detrimental effect.
Upon the registration of an application to the session daemon, its name
is sent as part of the 'struct lttng_ust_ctl_reg_msg' registration
message. The application name is sampled using lttng_pthread_getname_np
during the preparation of the message.
However, when the listener thread is launched, its name is changed
early-on to add a '-ust' suffix (see
01f0e40c). This suffixed name is
sampled and sent to the session daemon. Since, until recently, the
pthread_setname_np had no effect on most configurations, this had no
consequence.
I noticed that this has a ripple-effect in the generation of some
path names. For instance, in per-pid mode, snapshots end-up with the
following hierarchy:
/home/jgalar/lttng-traces
└── Mercury
└── florence_jacques-
20210514-162630
└── snapshot-0-
20210514-162726-1
└── ust
└── pid
└── hello-ust-332607-
20210514-162538
├── lol_0
├── lol_1
├── lol_10
├── lol_11
├── lol_2
├── lol_3
├── lol_4
├── lol_5
├── lol_6
├── lol_7
├── lol_8
├── lol_9
└── metadata
Notice how the 'hello' application presents itself with the '-ust'
prefix. For such a short application name, it doesn't really matter
much beyond repeating the 'ust' unnecessarily. However, longer
application names quickly become less readable as we lose four of
the 16 precious allowed characters for a process name.
The procname sampled during the execution of the constructors is
reused. My understanding is that the procname stored in the sock_info
is already used for the 'procname' context.
The resulting hierarchy becomes:
/home/jgalar/lttng-traces
└── Mercury
└── sylvie_rouillard-
20210514-193524
└── snapshot-0-
20210514-193553-0
└── ust
└── pid
└── hello-466576-
20210514-193514
├── lol_0
├── lol_1
├── lol_10
├── lol_11
├── lol_2
├── lol_3
├── lol_4
├── lol_5
├── lol_6
├── lol_7
├── lol_8
├── lol_9
└── metadata
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ibd6f4763c96ea5fb680f55e5cc3d250baca175b0
Michael Jeanson [Tue, 27 Apr 2021 16:14:15 +0000 (12:14 -0400)]
Add abi0 conflict tests
Add tests to make sure abi0 detection works properly in different
linking and dlopen scenarios.
Change-Id: I70927298163e5961e255250f7d8d6dd849d9d135
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 27 Apr 2021 16:13:04 +0000 (12:13 -0400)]
Detect unsupported use of .so.0 and .so.1 libraries within same process
Abort process if unsupported use of liblttng-ust and
liblttng-ust-tracepoint .so.0 vs .so.1 within the same process
is detected.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I2842ec43bf8840ddf88e0dd04bddb4c9e04e3a04
Michael Jeanson [Thu, 13 May 2021 22:41:35 +0000 (18:41 -0400)]
Add critical log level
Rename the unused BUG() macro to CRIT() to signify an error that can't
be recovered from. Add a new environment variable
LTTNG_UST_ABORT_ON_CRITICAL that when set will abort() on a critical log
statement.
Change-Id: Ib3384a66b7efa4004677b3c153f86cb97b06a091
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 14 May 2021 19:24:27 +0000 (15:24 -0400)]
Fix: shutdown communication socket on -EINVAL
Found by Coverity:
>>> CID
1453150: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "(void)ustcomm_shutdown_unix...".
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I151e86167e8467ce3b602ddd0258284e0ef53eaa
Mathieu Desnoyers [Thu, 13 May 2021 14:02:42 +0000 (10:02 -0400)]
Fix: lttng-ust control protocol handling of variable length command data
The scheme for sending variable length data and file descriptors after
the command message causes irrecoverable "unknown commands" errors when
communicating with older versions of lttng-ust, because the receiver
(lttng-ust in applications) does not know that it needs to consume the
variable length data on the communication socket.
For the new commands introduced in the 2.13 cycle, we can change the
protocol on both ends (liblttng-ust-ctl and liblttng-ust) now to add
a reply to the fixed-size part of the command before sending the
variable length data and file descriptors.
For pre-existing commands sending variable length data and file
descriptors right after the fixed-size command, handle this
irrecoverable "unknown command" error by doing a socket shutdown from
liblttng-ust-ctl.
Also document the protocol for each command sending variable length data
and file descriptors after the fixed-size command structure.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: If048c739dd37147ffb2a54715c2101177d2df4f7
Mathieu Desnoyers [Thu, 13 May 2021 13:55:49 +0000 (09:55 -0400)]
ustcomm: implement shutdown API
Implement socket shutdown API to allow the ust-ctl library to shutdown
the communication socket when it cannot recover from errors which make
the sender and receiver out-of-sync.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: If896396d9104b21aee09981cac773996ed79aa4d
This page took 0.054552 seconds and 5 git commands to generate.
projects / lttng-ust.git / log
