Kienan Stewart [Fri, 22 Nov 2024 14:17:50 +0000 (09:17 -0500)]
Fix: Correct `numa_available` return code checks
As of 0.9.2, the documentation has been updated to state that
`numa_available` returns `-1` on failure[1]. In
previous versions the documentation stated "any negative value",
although `-1` appears to be the only error return value as far back as
v0.5[2].
`0` should be considered a successful response when checking the
return code of this function.
Tests: Fix abi conflict test when building with clang
When building lttng-ust with clang, the following tests in
`tests/regression/abi0-conflict/test_abi0_conflict` fail:
```
not ok 12 - dlopen: no-ust app with abi1 and abi0 fails
not ok 14 - dlopen: ust app with abi0 fails
not ok 15 - dlopen: ust app with abi0 and abi1 fails
not ok 16 - dlopen: ust app with abi1 and abi0 fails
```
Cause
=====
With the default optimizations that are applied, clang seems to inline
the `init_uster` function.
Compiling with `-O0` lets the test pass.
Solution
========
Add the noinline attribute to the `init_uster` function in libfakeust0.
Change-Id: I4a3b16da2c8aad1840cb5e878231b63ca4d47618 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Kienan Stewart [Mon, 5 Aug 2024 19:41:34 +0000 (15:41 -0400)]
Fix: Build examples when rpath is stripped from in-build-tree libs
Observed issue
==============
Certain tool chains[1, 2] emit warnings or errors when building the
example applications.
```
make[3]: Entering directory
'/home/xxx/src/efficios/lttng/master/src/lttng-ust/doc/examples/easy-ust'
CC sample.o
CC tp.o
CCLD sample
/usr/bin/ld: warning: liblttng-ust-common.so.1, needed by ../../../src/lib/lttng-ust/.libs/liblttng-ust.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: liblttng-ust-tracepoint.so.1, needed by ../../../src/lib/lttng-ust/.libs/liblttng-ust.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_add_fd_to_tracker'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_after_fork_child'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_common_ctor'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_tp_init'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_tp_probe_register_queue_release'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_cancelstate_disable_pop'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_synchronize_rcu'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_register_thread'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_tp_probe_prune_release_queue'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_cancelstate_disable_push'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_before_fork'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_lock_fd_tracker'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_trace_clock'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_has_sys_membarrier'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_unlock_fd_tracker'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_tp_exit'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_get_cpu_sym'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_common_alloc_tls'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_after_fork_parent'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_delete_fd_from_tracker'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_register'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_reader'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_urcu_gp'
/usr/bin/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `lttng_ust_tp_probe_unregister_queue_release'
collect2: error: ld returned 1 exit status
```
=== Reproducer ===
The easiest way to consistently reproduce this type of build failure
is to perform the following steps:
```
./configure
make -j$(nproc)
find . -iname '*.so' -exec chrpath -d {} \;
make -C doc/examples clean
make -j$(nproc)
```
As the examples are not built with libtool, finding the libraries to
link against depends on the shared objects having an rpath.
The current examples build with `-Wl,-rpath` for `liblttng-ust`, but
not the dependencies of `liblttng-ust` (which would normally be found
via it's own rpath). If the `rpath` is stripped from
`liblttng-ust.so`, or if the tool chain ignores `rpath` explicitly,
then the build with fail.
In the case of a yocto build environment as in GitHub#61[1], the
following commands reproduced the warnings and the errors seen in the
above test case.
Explicitly add library search paths and set linker rpath-link are set
for both the standard and cmake examples. Similar changes were
proposed for each of those parts respectively in GitHub#61[1] and GitHub#63[2].
=== Known issues ===
While the `rpath-link` for the second order library dependencies will
allow the builds to complete, the examples will not work at
runtime even when using `rpath`. From `man ld.so`, the rpaths in an
executable or shared object are only considered for direct
dependencies. Therefore, without setting `LD_LIBRARY_PATH` or
installing the libraries test applications will fail as follows:
```
$ ./doc/examples/easy-ust/sample
./doc/examples/easy-ust/sample: error while loading shared libraries: liblttng-ust-common.so.1: cannot open shared object file: No such file or directory
```
Introduce two extension points for trace hit counters:
1) Future "actions" to perform other than "increment",
2) Future dimension indexing schemes (keys) other than tokens.
Ensure the LTTng-UST protocol with session daemon has those extension
points so we don't need to break ABI when we need to extend trace hit
counters with those features.
Also ensure the ABI between the tracepoint probe provider and the
tracer passes all the relevant context for future features, e.g.
tracepoint arguments and contexts.
Change the layout of struct lttng_ust_abi_counter_key_dimension
by adding a "key_type" field. A new struct lttng_ust_abi_counter_key_dimension_tokens
inherits from struct lttng_ust_abi_counter_key_dimension, and contains
the uint32_t nr_key_tokens field. The only currently supported key_type
is LTTNG_UST_ABI_KEY_TYPE_TOKENS = 0.
Change the layout of struct lttng_ust_abi_counter_event by adding an
"action" field. The only currently supported action is
LTTNG_UST_ABI_COUNTER_ACTION_INCREMENT = 0.
Change the struct lttng_ust_abi_key_token_string so it inherits from
struct lttng_ust_abi_key_token. The "len" field of
struct lttng_ust_abi_key_token now includes the length of the entire
child structure.
Change the newly introduced ABI between probe providers to change the
"event_counter_add" callback into a "counter_hit" callback, which takes
one less argument (no integer value), but takes additional stack_data,
probe_ctx, and event_counter_ctx arguments for future use.
Introduce a new LTTNG_UST_CTL_NOTIFY_CMD_KEY notification command to
separate key notifications from event notifications, given that they
require different arguments.
Revert back the register event notification to return a 32-bit event ID:
there is no point in changing the pre-existing protocol for event
registration now that key registration gets its own protocol commands.
Note that the protocol major is left at 10 even though we revert the
event ID change, because the protocol was bumped to 10 due to a
different change:
commit f63969cc383c ("dynamic-type: remove underscore prefix from mapping names")
Eliminate iteration over unmodified enablers when synchronizing the
enablers vs event state.
The intent is to turn a O(m*n) algorithm (m = number of enablers, n =
number of event probes) into a O(n) when enabling many additional events
when tracing is active.
This change is done both for event enablers and for event notifier
enablers.
[ Re-introduce commit after integration of Trace Hit Counters. ]
Bump LTTNG_UST_ABI_MAJOR_VERSION from 9 to 10, but keep backward
compatibility unchanged (oldest compatible 8) for applications linked
against older liblttng-ust.
With this protocol bump, we can send a 64-bit "id" in the event
registration reply. We keep the 32-bit event id field for now, until we
can proceed to bump the oldest compatible major number.
The 64-bit id field is useful for events within "counter" channels, but
there is no point in keeping a 32-bit value solely for the ring buffer
channel.
Naming timestamps "TSC" or "tsc" is an historical artefact dating from
the implementation of libringbuffer, where the initial intent was to use
the x86 "rdtsc" instruction directly, which ended up not being what was
done in reality.
Rename uses of "TSC" and "tsc" to "timestamp" to clarify things and
don't require reviewers to be fluent in x86 instruction set.
Kienan Stewart [Thu, 2 May 2024 20:51:45 +0000 (16:51 -0400)]
docs: Correct GitHub URLs in lttng-ust.3
The branches follow the format `stable-X.YZ` rather than `vX.YZ`.
Furthermore, when rendering the man pages from source, the URLs were
omitted completely as the subsitution `{lttng_version}` was not
defined. This hasn't been an issue for the published HTML versions as
those are produced via a different script in the `lttng-www` project
which presumably sets the substitution properly.
Change-Id: Ib96c99df13ddf724e128f95e7ce7c74b2c10c766 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
fix: handle EINTR correctly in get_cpu_mask_from_sysfs
If the read() in get_cpu_mask_from_sysfs() fails with EINTR, the code is
supposed to retry, but the while loop condition has (bytes_read > 0),
which is false when read() fails with EINTR. The result is that the code
exits the loop, having only read part of the string.
Use (bytes_read != 0) in the while loop condition instead, since the
(bytes_read < 0) case is already handled in the loop.
Original fix in liburcu from Benjamin Marzinski <bmarzins@redhat.com>:
commit 9922f33e2986 ("fix: handle EINTR correctly in get_cpu_mask_from_sysfs")
commit 4d4838bad480 ("Use MAP_POPULATE to reduce pagefault when available")
was first introduced in tag v2.11.0 and never backported to stable
branches. Its purpose was to reduce the tracer fast-path latency caused
by handling minor page faults the first time a given application writes
to each page of the ring buffer after mapping them. The discussion
thread leading to this commit can be found here [1]. When using
LTTng-UST for diagnosing real-time applications with very strict
constraints, this added latency is unwanted.
That commit introduced the MAP_POPULATE flag when mapping the ring
buffer pages, which causes the kernel to pre-populate the page table
entries (PTE).
This has, however, unintended consequences for the following scenarios:
* Short-lived applications which write very little to the ring buffer end
up taking more time to start, because of the time it takes to
pre-populate all the ring buffer pages, even though they typically won't
be used by the application.
* Containerized workloads using cpusets will also end up having longer
application startup time than strictly required, and will populate
PTE for ring buffers of CPUs which are not present in the cpuset.
There are, therefore, two sets of irreconcilable requirements:
short-lived and containerized workloads benefit from lazily populating
the PTE, whereas real-time workloads benefit from pre-populating them.
This will therefore require a tunable environment variable that will let
the end-user choose the behavior for each application.
Solution
--------
Allow users to specify whether they want to pre-populate
shared memory pages within the application with an environment
variable.
LTTNG_UST_MAP_POPULATE_POLICY
If set, override the policy used to populate shared memory pages within the
application. The expected values are:
none
Do not pre-populate any pages, take minor faults on first access while
tracing.
cpu_possible
Pre-populate pages for all possible CPUs in the system, as listed by
/sys/devices/system/cpu/possible.
Default: none. If the policy is unknown, use the default.
Choice of the default
---------------------
Given that users with strict real-time constraints already have to setup
their tracing with specific options (see the "--read-timer"
lttng-enable-channel(3) option [2]), it makes sense that the default
is to lazily populate the ring buffer PTE, and require users with
real-time constraints to explicitly enable the pre-populate through an
environment variable.
Effect on default behavior
--------------------------
The default behavior for ring buffer PTE mapping will be changing across
LTTng-UST versions in the following way:
glibc 2.34 implements close_range(2), which is used by the ssh client
(amongst others). This needs to be overridden to make sure ssh does not
close lttng-ust file descriptors.
Olivier Dion [Thu, 21 Mar 2024 18:42:13 +0000 (14:42 -0400)]
lttng-ust(3): Fix wrong len_type for sequence
`len_type' of a sequence field must be of type unsigned integer. Some
provided examples in the man page were incorrectly using a type signed
integer, resulting in correct compilation, but error while decoding.
Change-Id: Icc685b330d0704660b36f703075f453d71c5e4cb Signed-off-by: Olivier Dion <odion@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Kienan Stewart [Fri, 9 Feb 2024 19:18:59 +0000 (14:18 -0500)]
Fix: python lttngust agent fails when LTTNG_UST_APP_PATH is not set
Observed issue
==============
lttng-tools `tests/regression/ust/python-logging/test_python_logging`
had the following failures:
```
not ok 14 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 27 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 40 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 53 - Found 0 / 5 events matching 'python-ev-test1' out of 0 events
not ok 66 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 74 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 82 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 98 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 109 - Found 0 / 5 events matching 'python-ev-test1' out of 0 events
not ok 115 - Found 0 events matching 'python-ev-test1'
not ok 121 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 127 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 134 - Found 0 / 10 events matching 'python-ev-test1' amongst 0 events
not ok 140 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 146 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 157 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
```
Cause
=====
When the use of `LTTNG_UST_APP_PATH` was introduced[1], no default
value for `ust_app_port` was set. In the case where
`LTTNG_UST_APP_PATH` is not set in the environment the condition for
starting with the `ust_app_port` is still checked, causing the
following exception:
```
[2559145.907503] LTTng-UST warning: _init_threads(): cannot create client threads: cannot access local variable 'ust_app_port' where it is not associated with a value
```
Kienan Stewart [Tue, 28 Nov 2023 19:39:23 +0000 (14:39 -0500)]
Fix java client connection path when LTTNG_UST_APP_PATH is set
When LTTNG_UST_CTL_PATH is set for `lttng-sessiond`, the agent port is
at `$LTTNG_UST_CTL_PATH/agent.port`, not
`$LTTNG_UST_CTL_PATH/.lttng/agent.port`.
Change-Id: I79419f36cbd802da06acd68f58e437b0d4eb3856 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Introduce an environment to specify a path under which unix sockets
used for the communication between the application (tracee) instrumented
with `liblttng-ust` and the LTTng session and consumer daemons (part of
the LTTng-tools project) are located. When `$LTTNG_UST_APP_PATH` is
specified, only this path is considered for connecting to a session
daemon. Setting this environment variable disables connection to root
and per-user session daemons.
The `$LTTNG_UST_APP_PATH` target directory must exist and be accessible
by the user before the application is executed for tracing to work.
This environment variable affects the Java and Python agents in the same
way.
This environment variable on the LTTng-UST application side is meant to
be used with a new LTTNG_UST_CTL_PATH on the lttng sessiond side.
Fix: libc wrapper: use initial-exec for malloc_nesting TLS
Use the initial-exec TLS model for the malloc_nesting nesting guard
variable to ensure that the glibc implementation of the TLS access don't
trigger infinite recursion by calling the memory allocator wrapper
functions, which can happen with global-dynamic.
Considering that the libc wrapper is meant to be loaded with LD_PRELOAD
anyway (never with dlopen(3)), we always expect the libc to have enough
space to hold the malloc_nesting variable.
In addition to change the malloc_nesting from global-dynamic to
initial-exec, this removes the URCU TLS compatibility layer from the
libc wrapper, which is a good thing: this compatibility layer relies
on pthread key and calloc internally, which makes it a bad fit for TLS
accesses guarding access to malloc wrappers, due to possible infinite
recursion.
Michael Jeanson [Thu, 6 Jul 2023 18:40:01 +0000 (14:40 -0400)]
Tests: implement REUSE with SPDX identifiers
The SPDX identifiers [1] are a legally binding shorthand, which can be
used instead of the full boiler plate text. This is the first step
towards implementing the full REUSE spec [2] to help with copyright and
licensing audits and compliance.
This will reduce a lot a manual work required for the licensing audit
required in Debian on each update.
For files that lacked copyright and licensing information, I used the
following guidelines. If a clear author could be determined from the git
history use it, otherwise use 'EfficiOS Inc.'. For build system files,
use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'.
Freeform text files were converted to Markdown to allow licensing
comments.
Michael Jeanson [Thu, 6 Jul 2023 18:40:15 +0000 (14:40 -0400)]
doc: implement REUSE with SPDX identifiers
The SPDX identifiers [1] are a legally binding shorthand, which can be
used instead of the full boiler plate text. This is the first step
towards implementing the full REUSE spec [2] to help with copyright and
licensing audits and compliance.
This will reduce a lot a manual work required for the licensing audit
required in Debian on each update.
For files that lacked copyright and licensing information, I used the
following guidelines. If a clear author could be determined from the git
history use it, otherwise use 'EfficiOS Inc.'. For build system files,
use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'.
Freeform text files were converted to Markdown to allow licensing
comments.
Michael Jeanson [Thu, 6 Jul 2023 18:40:39 +0000 (14:40 -0400)]
include: implement REUSE with SPDX identifiers
The SPDX identifiers [1] are a legally binding shorthand, which can be
used instead of the full boiler plate text. This is the first step
towards implementing the full REUSE spec [2] to help with copyright and
licensing audits and compliance.
This will reduce a lot a manual work required for the licensing audit
required in Debian on each update.
For files that lacked copyright and licensing information, I used the
following guidelines. If a clear author could be determined from the git
history use it, otherwise use 'EfficiOS Inc.'. For build system files,
use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'.
Freeform text files were converted to Markdown to allow licensing
comments.
Michael Jeanson [Thu, 6 Jul 2023 18:40:50 +0000 (14:40 -0400)]
src: implement REUSE with SPDX identifiers
The SPDX identifiers [1] are a legally binding shorthand, which can be
used instead of the full boiler plate text. This is the first step
towards implementing the full REUSE spec [2] to help with copyright and
licensing audits and compliance.
This will reduce a lot a manual work required for the licensing audit
required in Debian on each update.
For files that lacked copyright and licensing information, I used the
following guidelines. If a clear author could be determined from the git
history use it, otherwise use 'EfficiOS Inc.'. For build system files,
use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'.
Freeform text files were converted to Markdown to allow licensing
comments.
Michael Jeanson [Thu, 6 Jul 2023 16:03:04 +0000 (12:03 -0400)]
Build system: implement REUSE with SPDX identifiers
The SPDX identifiers [1] are a legally binding shorthand, which can be
used instead of the full boiler plate text. This is the first step
towards implementing the full REUSE spec [2] to help with copyright and
licensing audits and compliance.
This will reduce a lot a manual work required for the licensing audit
required in Debian on each update.
For files that lacked copyright and licensing information, I used the
following guidelines. If a clear author could be determined from the git
history use it, otherwise use 'EfficiOS Inc.'. For build system files,
use 'MIT', for documentation 'CC-BY-4.0' and for data files 'CC0-1.0'.
Freeform text files were converted to Markdown to allow licensing
comments.
Michael Jeanson [Thu, 14 Dec 2023 15:46:56 +0000 (10:46 -0500)]
fix: -Wsingle-bit-bitfield-constant-conversion with clang16
We get the following warning with Clang 16:
lttng-ust-abi.c:558:38: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
lttng_chan_buf->priv->parent.tstate = 1;
My understanding is that there is no bug because we only check if the
values are zero or not, so we can silence the warning by making the
variables unsigned.
Change-Id: Ic4e02164d5adf4271fa24e5b13e5d320ae19de2e Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
After discussion with Jeremie, we want to introduce two (not one)
environment variables:
- LTTNG_UST_APP_PATH,
- LTTNG_UST_CTL_PATH.
to accomodate use-cases where a sessiond within a container is traced by
a sessiond in the parent container. In that situation, we want the
sessiond in the parent container to access the tracee through the
LTTNG_UST_CTL_PATH, without making the unix sockets for tracing control
visible to the child container.
Therefore, remove the LTTNG_UST_HOME environment variable before it is
added into an official release.
Michael Jeanson [Tue, 17 Oct 2023 19:02:44 +0000 (15:02 -0400)]
fix: clean java inner class files in examples
Java classes that contain inner classes will result in additional class
files being created when compiled in the form of
'Class$InnerClass.class'. Expand the clean target to delete those
additional files.
Change-Id: I0ed7939dcaefa5ca26db9438f7a9b34e57d78f21 Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jonathan Rajotte [Tue, 28 Sep 2021 21:47:31 +0000 (17:47 -0400)]
Add support for LTTNG_UST_HOME
Namespacing the LTTNG_HOME env variable facilitates the work carried to
have a way to trace the tracer (lttng-sessiond). This also fits with
the work done lately to namespace lttng-ust.
The LTTNG_HOME environment variable is used by lttng-sessiond to setup
the whole tracing environment for the application to be traced. When
lttng-ust is loaded by the lttng-sessiond to be traced, the fact that it
reuse the `LTTNG_HOME` set for the lttng-sessiond prevent us from
specifying an external lttng-sessiond home.
Albeit it could be possible for the lttng-sessiond to "trace" itself
(self tracing), it make more sense, in our testing environment, to have
a supplementary lttng-sessiond handling the tracing of the
lttng-sessiond under testing.
Note that some work will be carried to limit the use of LTTNG_HOME to
setup the tracing environment by lttng-sessiond and liblttng-ctl APIs
but it will be a long effort. Providing `LTTNG_UST_HOME` allows us to
start dogfooding today.
`LTTNG_HOME` is still used as a fallback to `LTTNG_UST_HOME` to preserve
backward compatibility.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I6aed21fd70d1b79b6768d237f59cc80612938d65
Kienan Stewart [Wed, 11 Oct 2023 14:28:40 +0000 (10:28 -0400)]
Log path used in connection attempts
Motivated by feedback on the lttng-dev mailing list that a user couldn't
find the socket path used when debugging connection issues of their
UST application.
Refs https://bugs.lttng.org/issues/1393
Change-Id: I42c8bb9ae372683a16f176caf87ac394f816955e Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Eliminate iteration over unmodified enablers when synchronizing the
enablers vs event state.
The intent is to turn a O(m*n) algorithm (m = number of enablers, n =
number of event probes) into a O(n) when enabling many additional events
when tracing is active.
This change is done both for event enablers and for event notifier
enablers.
Running the LTTng-tools tests (test_valid_filter, for example) under
address sanitizer results in the following warning:
/usr/include/lttng/urcu/static/urcu-ust.h:155:6: runtime error: member access within misaligned address 0x7fc45db3a020 for type 'struct lttng_ust_urcu_reader', which requires 128 byte alignment
0x7fc45db3a020: note: pointer points here
c4 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
While the node member of lttng_ust_urcu_reader has an "aligned"
attribute of CAA_CACHE_LINE_SIZE, the compiler can't ensure the
alignment of members for dynamically allocated instances.
The `data` pointer is changed from char* to struct
lttng_ust_urcu_reader*, allowing the compiler to enforce the expected
alignment constraints.
Since `data` was addressed in bytes, the code using this field is
adapted to use element counts. As the chunks are only used to allocate
reader instances (and not other types), it makes the code a bit easier
to read.
Olivier Dion [Tue, 22 Aug 2023 15:28:36 +0000 (11:28 -0400)]
ustfork: Initialize libc pointers in constructor
Instead of resolving individual libc functions lazily at their call
site, resolve every libc functions in a global constructor. This improve
error reporting for the user, by only emiting a single warning for each
failed symbol lookup.
Change-Id: I47504846e44a68366870b983ff556158e634cf83 Signed-off-by: Olivier Dion <odion@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Olivier Dion [Tue, 15 Aug 2023 14:47:06 +0000 (10:47 -0400)]
ustfork: Fix warning about volatile qualifier
Clang is strict about the volatile qualifier on function pointers. It
also wants pointers to be passed to atomic builtins, even for
functions. Therefore, use the addresses of function pointers even if
unnecessary according to C standard.
Change-Id: I5d553a46671cc4bfbe8de5cec2425201459f60d2 Signed-off-by: Olivier Dion <odion@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Olivier Dion [Wed, 9 Aug 2023 21:35:40 +0000 (17:35 -0400)]
ustfork: Fix possible race conditions
Assuming that `dlsym(RTLD_NEXT, "symbol")' is invariant for "symbol",
then we could think that memory operations on the `plibc_func' pointers can
be safely done without atomics.
However, consider what would happen if a load to a`plibc_func' pointer
is torn apart by the compiler. Then a thread could see:
1) NULL
2) The stored value as returned by a dlsym() call
3) A mix of 1) and 2)
The same goes for other optimizations that a compiler is authorized to
do (e.g. store tearing, load fusing).
One could question whether such race condition is even possible for the
clone(2) wrapper. Indeed, a thread must be cloned to get into
existence. Therefore, the main thread would always store the value of
`plibc_func' at least once before creating the first sibling thread,
preventing any possible race condition for this wrapper. However, this
assume that the main thread will not call the clone system call directly
before calling the libc wrapper! Thus, to be on the safe side, we do the
same for the clone wrapper.
Fix the race conditions by using the uatomic_read/uatomic_set functions,
on access to `plibc_func' pointers.
Change-Id: Ic4be25983b8836d2b333f367af9c18d2f6b75879 Signed-off-by: Olivier Dion <odion@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 14 Jun 2023 20:55:28 +0000 (16:55 -0400)]
fix: python agent: use stdlib distutils when setuptools is installed
When the setuptools package is installed, it monkey patches the standard
library distutils even if the user code doesn't import setuptools.
This results in a failure to install the python agent in a directory
which ins't in the current PYTHONPATH. To allow this setuptools requires
the '--single-version-externally-managed' options which is not
implemented in distutils.
To resolve this, force the use of distutils for python < 3.12 even when
setuptools is installed with the 'SETUPTOOLS_USE_DISTUTILS' environment
variable and use the proper setuptools option with python >= 3.12 which
doesn't include distutils anymore.
Change-Id: Idf477ca61bed460c9f6be7f481fe3b84624f328c Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 14 Jun 2023 19:58:32 +0000 (15:58 -0400)]
fix: python agent: install on Debian python >= 3.10
Starting with Debian's Python 3.10, the default install scheme is
'posix_local' which is a Debian specific scheme based on 'posix_prefix'
but with an added 'local' prefix. This is the default so users doing
system wide manual installations of python modules end up in
'/usr/local'. This interferes with our autotools based install which
already defaults to '/usr/local' and expect a provided prefix to be used
verbatim.
Monkeypatch sysconfig to override this scheme and use 'posix_prefix' instead.
Change-Id: I08fe77b6c8807515765e3ad0344aa6849e573b90 Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
projects / lttng-ust.git / log
