Michael Jeanson [Wed, 2 Feb 2022 20:04:09 +0000 (20:04 +0000)]
Add a Log4j 2.x agent specific domain 'log4j2'
The initial version of the new LTTng-UST Log4j 2.x agent only operated
in a compatibility mode making use of the existing 'log4j' tracing
domain currently implemented in LTTng-Tools.
While this is useful when migrating existing Log4j applications using
the compatibility bridge it does require converting the log levels from
the new Log4j 2.x values to the old Log4j 1.x standard. This results in
hiding the actual log level values from the users for applications
natively using Log4j 2.x.
Exposing the native Log4j 2.x log level values requires a new domain
since the changes are significant:
* The same list of standard log levels and names
* Each standard log level has a new integer value
* The log levels scale is reversed and shortened from
'int32_max -> int32_min' to '0 -> int32_max'
* The interval between standard log levels has changed
This new 'log4j2' domain is basicaly a straight copy of the current
'log4j' domain with minor adjustements for the reversed and shortened
scale.
Change-Id: I89f9c0a428ffe1d0bd26f7af547e9e21503de653 Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Two auto-generated files cause clang-format < v17 to hang when
they are being formatted. I have not looked into the root-cause,
but formatting them is useless anyhow.
Adding them to .clang-format-ignore works around the problem for the
moment.
Since clang-format 14 does not support ignore files, their support is
crudely emulated here using grep to filter out find's results.
Kienan Stewart [Wed, 10 Jul 2024 18:14:14 +0000 (14:14 -0400)]
Fix: Crash when unregistering UST apps during shutdown
Observed issue
==============
The following crash has been observed in v2.12.2:
```
function=0x55ac7c4c9600 <_ PRETTY FUNCTION .12873> "lttng_ustconsumer_close_metadata") at assert.c:92
function=0x55ac7c4c9600 <_ PRETTY FUNCTION .12873> "lttng_ustconsumer_close_metadata") at assert.c:101
```
The underlying cause is applicable in the current master branch as
well.
Cause
=====
There is a potential race between the threads the consumerd control
thread which handles commands coming from the sessiond and the main
thread when shutting down a consumerd.
Is it possible that the following happens:
1. `destroy_metadata_stream_ht` has the locks on `consumer_data`,
`channel`, `stream`
2. `lttng_ustconsumer_close_all_metadata` looks up the channel and starts to try and acquire a channel lock (`stream->chan->lock`)
3. `destroy_metadata_stream_ht` sets `stream->chan` to `null`
4. `destroy_metadata_stream_ht` releases the `stream`, `channel`, and `consumer_data` locks
5. `lttng_ustconsumer_close_all_metadata` now has the channel lock, and looks up `stream->chan` again to call `destroy_metadata_stream_ht`, and that member is now null
Solution
========
Acquire the stream lock after acquiring the channel lock.
part 2 follows: don't set stream->chan to null.
Known drawbacks
===============
None.
Change-Id: I1d27ea6ac08f3e7ed4624a8921cffb675be649d2 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Kienan Stewart [Tue, 6 Aug 2024 15:32:57 +0000 (11:32 -0400)]
Fix: Compilation failure deducing type of `auto` variables in GCC 4.8
Observed issue
==============
When compiling with GCC 4.8.5 or GCC 5.5.0 on SLES12SP5, the following
error happens:
```
save.cpp: In function 'int save_agent_events(config_writer*, agent*)':
save.cpp:1185:43: error: use of 'agent_event' before deduction of 'auto'
lttng::urcu::lfht_iteration_adapter<agent_event,
^ save.cpp:1185:43: error: use of 'agent_event' before deduction of 'auto'
save.cpp:1185:43: error: use of 'agent_event' before deduction of 'auto'
save.cpp:1187:26: error: template argument 1 is invalid
&agent_event::node>(*agent->events->ht)) {
^
save.cpp:1187:26: error: creating pointer to member of non-class type '<type error>'
save.cpp:1187:26: note: invalid template non-type parameter
In file included from ../../../src/vendor/fmt/core.h:3316:0,
from ../../../src/common/format.hpp:20,
from ../../../src/common/error.hpp:13,
from ../../../src/common/common.hpp:12,
from snapshot.hpp:13,
from consumer.hpp:12,
from session.hpp:11,
from kernel.hpp:13,
from save.cpp:10:
```
Cause
=====
This appears to be a limitation in older versions of GCC. I did not
find specific commit(s) or bugs which hilight the issue, but
compilation of this code works as of GCC 6.5.0 on SLES12SP5. Previous
point releases of GCC 6.x were not tested.
Solution
========
Explicitly define the type of the pointer and the type passed to
`lttng::urcu::lftht_iteration_adapter` so the compiler does not have
to perform type deduction.
Known drawbacks
===============
None.
Change-Id: I71c5937a38336756ece4f396ea5ba7af7f3d36c3 Signed-off-by: Kienan Stewart <kstewart@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Kienan Stewart [Tue, 6 Aug 2024 15:14:49 +0000 (11:14 -0400)]
Fix: Compilation failure in session_not_found_error with GCC 4.8
Observed issue
==============
When compiling with gcc 4.8.5, the compilation fails with the
following erorr:
```
session.hpp:577:2: error: function 'lttng::sessiond::exceptions::session_not_found_error::session_not_found_error(lttng::sessiond::exceptions::session_not_found_error&&)' defaulted on its first declaration with an exception-specification that differs from the implicit declaration 'lttng::sessiond::exceptions::session_not_found_error::session_not_found_error(lttng::sessiond::exceptions::session_not_found_error&&)'
session.hpp:577:2: error: function 'lttng::sessiond::exceptions::session_not_found_error::session_not_found_error(lttng::sessiond::exceptions::session_not_found_error&&)' defaulted on its first declaration with an exception-specification that differs from the implicit declaration 'lttng::sessiond::exceptions::session_not_found_error::session_not_found_error(lttng::sessiond::exceptions::session_not_found_error&&)'
```
Cause
=====
This is due a bug in GCC which is fixed as of GCC 5.0[1]
Solution
========
Do not explicitly define the move_assignable for
`lttng::sessiond::exceptions::session_not_found_error` as
`noexcept`. The function should be implicitly generated as `noexcept`.
Add a type-safe cds_list iteration adapter. Like those provided for
the lfht, this adapter provides type-safe range-for semantics for
cds_list structures.
The urcu lfht macros often make use of caa_container_of (and other equivalent
variations) which use offsetof. Unfortunately, offsetof is conditionally
supported by compilers for non-POD types.
The tree already has lttng::utils::container_of to work around this
problem. This new utils makes it possible to iterate on the
elements of an lfht that match a given key without using those macros. Those iterations are the
main reason such warnings are emitted. The interface of
lfht_filtered_iteration_adapter also allows the use of ranged-for loops.
Fix: sessiond: missing include causes multiple conflicting definitions
clang-tidy reports that
/root/lttng-tools/src/bin/lttng-sessiond/ust-ctl-internal.hpp:346:3: error: redefinition of 'LTTNG_PACKED' with a different type: 'struct lttng_ust_ctl_integer_type' vs 'struct lttng_ust_ctl_consumer_channel_attr' [clang-diagnostic-error]
346 | } LTTNG_PACKED;
Indeed, that header is missing macros.hpp causing LTTNG_PACKED
to be misinterpreted.
clang-tidy reports an infringement of
cppcoreguidelines-special-member-functions[1] for
_scoped_rcu_read_lock, iterator, session_not_found_error,
and session_not_found_error.
The copy constructor, move constructor, and assignment operators
are deleted when they are not explicitly defined.
sessiond: iterate on ust_app_ht using lfht_iteration_adapter
offsetof conditionally support for non-POD types and is used by
the cds_lfht_for_each_[...] macros. Replace them with
lfht_iteration_adapter which also provides ranged-for semantics.
sessiond: delete_ust_app_channel: iterate on lfht using lfht_iteration_adapter
offsetof conditionally support for non-POD types and is used by
the cds_lfht_for_each_[...] macros. Replace them with
lfht_iteration_adapter which also provides ranged-for semantics.
relayd: use lfht_iteration_adapter to iterate on stream indices
offsetof conditionally support for non-POD types and is used by
the cds_lfht_for_each_[...] macros. Replace them with
lfht_iteration_adapter which also provides ranged-for semantics.
The urcu lfht macros often make use of caa_container_of (and other
equivalent variations) which use offsetof. Unfortunately, offsetof is
conditionally supported by compilers for non-POD types.
The tree already has lttng::utils::container_of to work around this
problem. This new utils makes it possible to iterate on all of the
elements of an lfht without using those macros. Those iterations are the
main reason such warnings are emitted. The interface of
lfht_iteration_adapter also allows the use of ranged-for loops.
sessiond: manage syscall table allocation using std::vector
Transitioning to the use of std::vector to manage the allocation and
resizing of the syscall table allows us to do away with memset() of the
syscall structure. The memset becomes problematic when lttng_ht_node_*
becomes non-POD in a follow-up change.
cds_lfht_add_unique is misused in relay_index_add_unique. The address
of the node is used instead of the address of the key for both the
key parameter and to compute the hash of the index entry's key.
This caused problems in an upcoming change that changes the layout
of the lttng_ht node since the key is no longer the first member
of the node.
Adapt to ABI/control API updates introduced by LTTng-UST commit 24f7193c9b91 ("Introduce extension points for trace hit counters")
Note that this commit reverts back to uint32_t for channel event ids.
UST notification LTTNG_UST_CTL_NOTIFY_CMD_KEY is currently handled as
-LTTNG_UST_ERR_NOSYS (TODO).
The type of the argument to is_max_event_id() is changed to
lttng::sessiond::ust::event_id to match the newly introduced event_id
type definition. Likewise for the registry_channel _next_event_id
member.
projects / lttng-tools.git / log
