Fix: src.ctf.lttng-live: handle inconsistent stream class ID gracefully
Replace BT_ASSERT() with proper error handling when validating stream
class IDs received from the relay daemon. Since this is external network
data, inconsistent values should result in a graceful error rather than
an assertion failure which can, amongst other things, crash your whole
application if you're building a graph with libbabeltrace2 (or with the
Python bindings).
We ran into this within an LTTng-tools test when a change in LTTng-UST
merely changed the order in which data indexes vs. inactive stream
beacons happen, exposing an already present issue in the relay daemon.
lib: add `LIBBABELTRACE2_FORCE_COMPONENT_LOG_LEVEL` support
The new `LIBBABELTRACE2_FORCE_COMPONENT_LOG_LEVEL` environment variable
makes it possible to force the log level of all or specific components
added to any trace processing graph.
Its value is one of:
• A single log level value.
In this case, libbabeltrace2 overrides the log level specified when
adding _any_ component to any trace processing graph.
• A semicolon-delimited list of `PAT:LEVEL` specifiers.
`PAT` is a globbing pattern where only the wildcard character, `*`,
is special: it matches zero or more characters.
`LEVEL` is a log level value.
In this case, libbabeltrace2 overrides the log level specified when
adding a component of which the name matches `PAT` to any trace
processing graph.
The accepted log level values are the same as
with `LIBBABELTRACE2_INIT_LOG_LEVEL`.
libbabeltrace2 dynamically checks this environment variable before
adding a component to a trace processing graph, meaning you can modify
it at any time with setenv(3).
Example:
*ctf*:I;my-sink:D;*:W
This is useful for quick debugging when you don't control the component
additions, for example when using `bt2.TraceCollectionMessageIterator`
with an automatically discovered component. I added it at the
libbabeltrace2 level to make this available to any component addition.
OBSERVED ISSUE
━━━━━━━━━━━━━━
A `bt2.TraceCollectionMessageIterator` instance isn't deterministically
garbage-collected when losing its last reference.
This means the graph and all its components (and their resources,
including file descriptors) stay alive until a cyclic garbage
collection occurs.
tests/bindings: fix PackageTestCase always testing the same attribute
The way this test is written is not good. The function `test_func`,
defined inside the loop, does not capture the current value of `name`.
All test methods therefore test with the same `name` value. I confirmed
this with a print inside `PackageTestCase._assert_in_bt2`.
Change it to have an external function that returns the function to use
as the test method. This way, each test method will refer to its own
`name`.
I found this because I happened to have "flake8-bugbear" installed
locally, and flake8 showed this warning:
./test_package.py:309:29: B023 Function definition does not bind loop variable 'name'.
Run `pre-commit autoupdate` to bump the versions of the
linting/formatting tools.
The black version used to be limited by the Debian or Ubuntu version on
the CI. Now that the workers run the bleeding edge Debian 13, let's try
to go to the latest version.
flake8 complains with warnings such as:
src/bindings/python/bt2/bt2/graph.py:61:5: E704 multiple statements on one line (def)
It doesn't like the "..." that black now puts on the same line as the
function signature. The formatting is dictated by black, so ignore that
warning.
This patch adds partial documentation for what's "internally public" in
`src/cpp-common/bt2`.
Documenting all the files, types, and functions would be a very tedious
task because it's equivalent to the effort of documenting the whole
libbabeltrace2 C API. That being said, most of the `bt2` namespace is
straightforward if you already know the libbabeltrace2 C API.
I documented what might be less obvious to understand, namely:
• In `all.dox`:
‣ Quick start to show how the C++ bindings work in general.
‣ Gneral terminology.
‣ Borrowed object wrapper, optional wrapper.
‣ Shared object, reference counting, creation.
‣ How to create a new wrapper class.
‣ C++ component class development: usage and internals.
‣ C++ plugin development.
• The `bt2::BorrowedObjectIterator` class template.
• The `bt2::BorrowedObjectProxy` class template.
• The `bt2::BorrowedObject` class template.
• The `bt2::OptionalBorrowedObject` class template.
• The whole `component-class-dev.hpp` header.
• The whole `error.hpp` header.
• Exception classes in `exc.hpp`.
• The bt2::internal::validateCreatedObjPtr() function.
bt2::Graph: add user component class instantiation methods
This patch adds new templated bt2::Graph::addComponent() methods.
Those new ones are a combination of the existing addComponent() ones
and bt2::createComponentClass(), for example:
const auto myComp = myGraph.addComponent<MyFilterComp>("meow", params);
This is intended for simple use cases where you instantiate a component
class only once within the graph. Otherwise, it's still preferred to
create a component class first and then instantiate this one multiple
times with the non-templated bt2::Graph::addComponent() overload.
