Tests: rotation: add a per-pid size-based rotation test

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I8f6875567d52dd7d28000ff34fff47f992cdab3f

Tests: add a local size-based rotation test in per-uid buffering mode

This test runs an application up until we observe four archived traces.
Unfortunately, we can't validate their size since they are approximative.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Iecdbf3ee33ed02745a99e7af22c0645b4375413e

Fix: sessiond: report client list allocation failure as a fatal error

Report the failure to allocate a notification client list as a fatal
notification thread error.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I8f2654020d0d890cc9275d445fdeccde940d2ae0

Fix: leak of channel-bound trigger list element

The list element is never free'd when a channel-bound trigger
is unregistered.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I32c4ee4512c460363e3384c2e3aac9feff4343b1

Fix: sessiond: size-based rotation threshold exceeded in per-pid tracing (2/2)

For a complete description of the original problem, refer to the previous
commit.

This change implements the second part of the fix.

Buffer statistic samples are augmented to include the channel's session
id. Since a session can outlive its channels (on the session daemon
side), the consumed size conditions are now bound to the session.

This means that the "total consumed" state is now part of the
session_info structure exclusively which, overall, is cleaner.

A side-effect of this change is that consumed size conditions are now
also evaluated when a trigger is registered or when a client subscribes
to it via a notification channel instead of waiting until the next
monitoring sample.

The buffer statistics sample also expresses a "consumed size" that is
relative to the last sample that was successfully sent.

Finally, the consumer daemon sends a final buffer statistics sample when
a channel is torn down. As explained in more detail in the previous
commit, this makes the accounting of per-pid sessions more reliable when
short-live applications are traced.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I322b9f20977e59c63cf2a4254c97c4ee657e933e

Fix: sessiond: size-based rotation threshold exceeded in per-pid tracing (1/2)

Issue observed
--------------

When tracing short-lived applications with buffers configured in per-pid
mode, the size-based rotation threshold is often greatly exceeded. In
the CI, this occasionally causes the size-based rotation tests to
timeout for the per-pid case.

Cause
-----

There is a scenario where a session's consumed size is miscalculated.

When an application exits during per-pid tracing, both the session and
consumer daemons notice it. The session daemon sees the application's
command pipe hanging-up, while the consumer daemon sees the
application's data-ready pipe hanging-up.

Upon handling these events, both daemons tear down their representation of
the channels.

In an ideal world, we'd want to sample the streams' "consumed_size" at
the last possible moment to get the size of all consumed data for this
stream. However, this is problematic in the following scenario:
  - the sessiond destroys the channel before the consumer daemon,
  - the consumer daemon sends a final buffer stats sample on tear down,
  - the sessiond can do nothing with the sample as it doesn't know that
    channel anymore.

(Note that the session daemon gracefully handles the case where it
doesn't know a channel.)

When applications have a short lifetime and are traced in per-PID
buffering mode, there is a high likelihood that the last buffer
statistics sample sent for a given channel will target a channel that
the session daemon has already torn down.

Solution
--------

Consumed-size conditions are somewhat special: they are bound to a
session, but they are evaluated through a per-channel event (buffer
statistics samples taken by the channels' monitoring timer).

To work around the problem of lifetime of channels, we can rely
on the fact that sessions outlive channels to perform the accounting
of the consumed size.

This patch is the first step to implement this fix: new
notification-thread commands are introduced to announce the creation and
destruction of an `ltt_session`. Currently, the notification thread
implies the existence of a session by tracking its channels' creation
and destruction.

With this change, it no longer needs to do so; session are explicitly
created and destroyed. Their unique ID is also kept stored.

The key of `sessions_ht` becomes the `id` of the session to allow
efficient look-ups on the reception of a buffer statistics sample.

The existing callsites that make use of the session's name to perform a
look-up are modified to look-up the id by name (see
sample_session_id_by_name()).

The add/remove channel commands and rotation ongoing/completed commands
are modified to refer to sessions by ID since they can assume the
notification thread knows about the session.

Note
----

In a follow-up patch, buffer statistics samples are modified to include
the session's ID and the consumed size is modified to become a "delta"
relative to the previous sample associated with a given channel.

This makes it possible to perform the accounting of a session's consumed
size beyond the lifetime of its channels.

The follow-up patch is the "core" of the fix, but it requires these
prior changes.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I865e9ac5e1a63e62123209be63957dad28c588a8

consumerd: send a buffer static sample on flush command

When application exits during per-pid tracing, both the session and
consumer daemons notice it. The session daemon sees the application's
command pipe hanging-up, while the consumer daemon sees the
application's data-ready pipe hanging-up.

Upon handling this event, both daemons tear down their representation of
the channels.

In an ideal world, we'd want to sample the streams' "consumed_size" at the
last possible moment to get the size of all consumed data for this
stream. However, this is problematic in the following scenario:
  - the sessiond destroys the channel before the consumer daemon,
  - the consumer daemon sends a final buffer stats sample on tear down,
  - the sessiond can do nothing with the sample as it doesn't know that
    channel anymore.

Note that the session daemon handles the case where it doesn't know a
channel gracefully.

When an application being traced in per-pid mode is torn down, the
session requests a flush of its buffers to the consumer daemon. We can
use this opportunity to emit a buffer stats sample.

This is still racy since the tear down of the channel could complete on
the session daemon's end before that last sample can be processed. In
practice, though, it markedly improves the precision of size-based
rotations in per-pid tracing mode.

On my work machine, I see the size-based rotation tests pass with
archive sizes within ~10% of the size threshold. Before this, we lost a
lot of samples from short-lived buffers and it would not be rare to see
archives end-up multiple times (5x-10x) larger than the size-threshold.

Another problem is that the consumed_size returned by the consumer
daemon will not include the packets that have yet to be consumed.

Whether or not this is a fix is debatable since it arguably just
improves the precision of size-based rotations.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I8a72328ba1733ac2f50c77a1ff81d7a6aaac095c

consumerd: rename `data_read` to `has_data_left_to_be_read_before_teardown`

Document the sequence of events after a stream hangs up and rename
the `data_read` stream attribute to give it a more specific name.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id7d26fa04fc0d2f0875dced18b6a3f6a7fe7d139

Fix: ust-consumerd: set `hangup_flush_done` in a locked context

hangup_flush_done is updated after releasing the stream lock. This
doesn't appear to be a problem right now since this attribute is
apparently always accessed by the same thread, but it is conceptually
sus.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I191cb01b02c3d96e19034e0d0e80cb7f8dff2140

Fix: sessiond: size-based rotations never trigger

Issue observed
==============

Size-based scheduled rotations have no effect.

Cause
=====

Since c08136a3f, the rotation thread's handle_condition() checks that
the notification received matches the trigger that was registered.

As part of the equality check, the triggers' credentials are compared.

This checks fails systematically since the group id of a trigger's
credentials is not transported by the serialize/create_from functions.
The trigger that is received through the notification thus has an unset
group id, while the rotation trigger of the `ltt_session` has a group id
set; it was not stripped by the communication layer.

The check also fails since the trigger registered for the size-based
rotation is "hidden". This internal attribute is not propagated through
the communication layer, which causes the comparison to fail.

Solution
========

Since triggers only use the 'uid' part of lttng_credentials, we ensure
that lttng_trigger_set_credentials only sets this part of the structure.

Also, the `is_hidden` attribute of a trigger is now propagated through
the communication layer. This has no effect for external applications
since this attribute is not exposed through the API. However, it is
useful for internal triggers which use the same communication
facilities.

This allows the equality check in rotation-thread.cpp to go through as
expected.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I216f5cb9297ecd1a867dc292c10b8da595efce34

Bump URCU dependency to 0.14

Complete C++ support was introduced in Userspace-RCU 0.14, using earlier
versions results in a build failure, this should be reflected in the
configure check.

Change-Id: I1b708bd9b04784deb9f2c8768a331911c3ebb891
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
channel.cpp:584:2: warning: missing initializer for member 'lttng_notification_channel_message::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ia5a5f37f6fe6977169771e4a298d1ce73ab74ea4

Build fix: missing initializer for member 'override_name'

gcc 5.4.0 complains that:
relayd/relayd.cpp:1353:2: warning: missing initializer for member 'lttcomm_relayd_create_trace_chunk::override_name' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6607c46e4aa98017183f41fc8be9b0226b70cf29

Build fix: missing initializer for member 'rotate_positions'

gcc 5.4.0 complains that:
relayd/relayd.cpp:1221:2: warning: missing initializer for member 'lttcomm_relayd_rotate_streams::rotation_positions' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: If0ecd9c9b2c5a0861463e93a2a52b0d2b3a36712

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
notification.cpp:43:57: warning: missing initializer for member 'lttng_notification_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Iebb2f14df21f6db9dceaf708af6ef12efda1b929

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
event.cpp:1238:53: warning: missing initializer for member 'lttng_event_context_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id7c01cd19cbf884efd16734239cae8476b798c20

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
event.cpp:769:3: warning: missing initializer for member 'lttng_event_exclusion_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I22ccd0c84669951f6e0a13663e47b1d2a204d3a8

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
event.cpp:769:3: warning: missing initializer for member 'lttng_event_exclusion_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Iac3eedff2d79843c910b4da5edec4d7f10fa062a

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
error-query.cpp:777:2: warning: missing initializer for member '{anonymous}::lttng_error_query_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I1264bc2da7e8ff6ec6c740341a381b33bae643d1

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
error-query.cpp:570:2: warning: missing initializer for member '{anonymous}::lttng_error_query_results_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ib1a297eaf2fd75b908573ac252b433a14423add5

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
error-query.cpp:318:2: warning: missing initializer for member '{anonymous}::lttng_error_query_result_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie194864415bc3bc32bda6b2ac17150bd3f163394

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
evaluation.cpp:30:2: warning: missing initializer for member 'lttng_evaluation_comm::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I2784138b00af34b2bc47ed28097ab32afaa379d2

Build fix: missing initializer for member 'indexes'

gcc 5.4.0 complains that:
actions/path.cpp:191:7: warning: missing initializer for member '{anonymous}::lttng_action_path_comm::indexes' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3b365e89c6a11cf65f609a4e14ae972faa2a518d

Build fix: missing initializer for member 'payload'

gcc 5.4.0 complains that:
notification-thread-events.cpp:3755:2: warning: missing initializer for member 'lttng_notification_channel_message::payload' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I4e3f32da956764cd9beba6f4c72cfc48251b8203

Build fix: missing initializer for member 'rotation_positions'

gcc 5.4.0 complains that:
  main.cpp: In function 'ssize_t relay_unpack_rotate_streams_header(const lttng_buffer_view*, lttcomm_relayd_rotate_streams*)':
  main.cpp:2547:2: warning: missing initializer for member 'lttcomm_relayd_rotate_streams::rotation_positions' [-Wmissing-field-initializers]

The structure's members are initialized one by one.

At the same time, the use of the address of a packed
member (stream_count) is eliminated, which fixes another unrelated
warning emited by clang.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5fd90d75cc6e0ba17350fc8092929f476e93757e

Build fix: specialization of template in different namespace

Observed issue
==============

On older g++, such as gcc (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413:

make[3]: Entering directory '/tmp/virtenv/src/lttng-tools/src/bin/lttng-sessiond'
  CXX      utils.lo
In file included from ust-app.hpp:15:0,
                 from lttng-sessiond.hpp:22,
                 from utils.cpp:17:
../../../src/common/format.hpp:17:24: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
 DIAGNOSTIC_IGNORE_DUPLICATED_BRANCHES
                        ^
In file included from ust-app.hpp:15:0,
                 from lttng-sessiond.hpp:22,
                 from utils.cpp:17:
../../../src/common/format.hpp:23:13: error: specialization of 'template<class T, class Char, class Enable> struct fmt::v8::formatter' in different namespace [-fpermissive]
 struct fmt::formatter<std::type_info> : fmt::formatter<std::string> {
             ^
In file included from ../../../src/common/format.hpp:19:0,
                 from ust-app.hpp:15,
                 from lttng-sessiond.hpp:22,
                 from utils.cpp:17:
../../../src/vendor/fmt/core.h:707:8: error:   from definition of 'template<class T, class Char, class Enable> struct fmt::v8::formatter' [-fpermissive]
 struct formatter {
        ^
In file included from ust-registry.hpp:20:0,
                 from ust-app.hpp:19,
                 from lttng-sessiond.hpp:22,
                 from utils.cpp:17:
ust-registry-event.hpp:66:13: error: specialization of 'template<class T, class Char, class Enable> struct fmt::v8::formatter' in different namespace [-fpermissive]
 struct fmt::formatter<lttng::sessiond::ust::registry_event> : fmt::formatter<std::string> {
             ^
In file included from ../../../src/common/format.hpp:19:0,
                 from ust-app.hpp:15,
                 from lttng-sessiond.hpp:22,
                 from utils.cpp:17:
../../../src/vendor/fmt/core.h:707:8: error:   from definition of 'template<class T, class Char, class Enable> struct fmt::v8::formatter' [-fpermissive]
 struct formatter {
        ^
In file included from ust-app.hpp:19:0,
                 from lttng-sessiond.hpp:22,
                 from utils.cpp:17:
ust-registry.hpp: In constructor 'lttng::sessiond::ust::registry_typed_enum<MappingIntegerType>::registry_typed_enum(const char*, const lttng_ust_ctl_enum_entry*, size_t)':
ust-registry.hpp:111:45: error: 'lttng::sessiond::trace::integer_type::signedness' is not a class, namespace, or enumeration
       lttng::sessiond::trace::integer_type::signedness::SIGNED :
                                             ^
ust-registry.hpp:112:51: error: 'lttng::sessiond::trace::integer_type::signedness' is not a class, namespace, or enumeration
             lttng::sessiond::trace::integer_type::signedness::UNSIGNED),
                                                   ^
In file included from lttng-sessiond.hpp:22:0,
                 from utils.cpp:17:
ust-app.hpp: At global scope:
ust-app.hpp:330:13: error: specialization of 'template<class T, class Char, class Enable> struct fmt::v8::formatter' in different namespace [-fpermissive]
 struct fmt::formatter<ust_app> : fmt::formatter<std::string> {
             ^
In file included from ../../../src/common/format.hpp:19:0,
                 from ust-app.hpp:15,
                 from lttng-sessiond.hpp:22,
                 from utils.cpp:17:
../../../src/vendor/fmt/core.h:707:8: error:   from definition of 'template<class T, class Char, class Enable> struct fmt::v8::formatter' [-fpermissive]
 struct formatter {
        ^
cc1plus: warning: unrecognized command line option '-Wno-gnu-folding-constant'
cc1plus: warning: unrecognized command line option '-Wno-incomplete-setjmp-declaration'
Makefile:855: recipe for target 'utils.lo' failed
make[3]: *** [utils.lo] Error 1

This also applies to the following specializations:
  void lst::signed_enumeration_type::accept(type_visitor& visitor) const
  void lst::unsigned_enumeration_type::accept(type_visitor& visitor) const

Problem
=======

This is due to a now-fixed gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480

Solution
========

Put the template specializations inside the proper namespace.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6b931065b37e6e9ba97f87c754c15808506c2ba8

Build fix: old gcc does not recognize hidden/shadowed enumeration as valid

The build fails on GCC < 6 with:

ust-registry.hpp: In constructor 'lttng::sessiond::ust::registry_typed_enum<MappingIntegerType>::registry_typed_enum(const char*, const lttng_ust_ctl_enum_entry*, size_t)':
ust-registry.hpp:111:45: error: 'lttng::sessiond::trace::integer_type::signedness' is not a class, namespace, or enumeration
       lttng::sessiond::trace::integer_type::signedness::SIGNED :

The same error occurs for stream_class::header_type.

This is due to a bug fixed in gcc 6:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994

In both cases, the member is suffixed to disambiguate the reference to
the inner-enumeration.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id0f2f98a147be589b9c70740660c7fb911dfc22c

Build fix: unknown warning -Wduplicated-branches

-Wduplicated-branches was introduced in GCC 7. Only define
DIAGNOSTIC_IGNORE_DUPLICATED_BRANCHES for those more recent versions.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3b50a671867a74629519375801bf2b4f3c597cd8

Fix: pthread::mutex unlock must not throw

unlock() is often called by destructors (e.g. lock guard); it must not
throw. We don't expect unlock to fail given our current usage anyhow.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5dfd856f8a2dd29fd7c480c6ab6289b5b91c4391

Clean-up: common: uuid: uninitialized output parameter on error

1490018 Uninitialized scalar variable
The variable will contain an arbitrary value left from earlier
computations.

In lttng_uuid_from_str(char const *, std::​array<unsigned char, 16ul> &):
Use of an uninitialized variable (CWE-457)

Callers should not use the return parameter anyhow on error.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Idd863d219da840a0c291478733f7b931967a5e56

Fix: sessiond: registry_channel: initialize _rcu_head and _node

1490020 Uninitialized pointer field
The pointer field will point to an arbitrary memory location, any
attempt to write may cause corruption.

In lttng::​sessiond::​ust::​registry_channel::​registry_channel(unsigned int, std::​function<void (lttng::​sessiond::​ust::​registry_channel const &)>, std::​function<void (lttng::​sessiond::​ust::​registry_channel const &, lttng::​sessiond::​ust::​registry_event const &)>): A pointer field is not initialized in the constructor (CWE-457)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie043af750941a02a65ba69e70fe2620349989398

sessiond: registry_event: remove lttng_ht_node_u64 wrapper

Use rcu_head and cds_lfht_node directly since the lttng_ht_node_u64
utils is unused anyhow: its key is never initialized.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id8b8d4b2f9ca9137b859844bc70e9d02e9fa2975

Tests: test_uuid: unchecked return value

1490026 Unchecked return value
If the function returns an error value, the error value may be mistaken
for a normal value.

In run_test_lttng_uuid_is_equal(): Value returned from a function is not
checked for errors before being used (CWE-252)

Reported-by: Coverity Scan
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id9558a07ebcc47f5630deed32f5a457ba002bfe6

Fix: common: uninitialized lttng::ctl:error field

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I456d1811c3827472533d0531af7148ee6e7eb34b

common: replace container_of with a C++ safe implementation

As more code moves to a more idiomatic C++ style, structures like
typically end up becoming classes that use different access controls,
virtual functions, etc. This, in turn, makes them adopt a non standard
layout and causes GCC and clang to emit the following warning when
container_of is used:

error: 'offsetof' within non-standard-layout type 'foo' is conditionally-supported [-Werror=invalid-offsetof]

This new implementation of container_of makes use of a pointer to a data
member to find the parent's address.

The use of ptr_to_member against the null dummy_parent makes me uneasy
as it seems equivalent to performing arithmetic on a null pointer, which
I understand is undefined behavior (C++11 Standard 5.7.5).

However, Boost.Instrusive uses an approach that seems roughly equivalent
to lttng::utils::container_of() [1].

It seems like a reasonable compromise that works on all mainstream
compilers.

[1] https://github.com/boostorg/intrusive/blob/3c5c8cec3f0356a028a4b56ba6cac2256340dab1/include/boost/intrusive/detail/parent_from_member.hpp#L92

Change-Id: Ia6287e1648bce85dfe6de936f17ec5df46ea648d
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

sessiond: registry_session: mark functions as noexcept

Mark functions destroy_channel and _destroy_enum as noexcept as they are
used by the registry_session destructor (which must not throw).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie7bbbf349f14f5691b52873fe8ba6556be143d93

Clean-up: sessiond: move registry_session free functions under class

Move a number of registry_session methods implemented as c-style
free functions under the `registry_session` class. This makes it
possible to make a large number of attributes private.

This leaves only the metadata storage and locking facilities
publicly accessible. Making them private requires a bit more
refactoring.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6bdd4cc8918e5d7025fc3d735fadbf1ce2e9b7c8

Clean-up: sessiond: move ust_registry_session under lttng::sessiond::ust

The ust_registry_session* class hierarchy is namespaced under
lttng::sessiond::ust.

The registry session classes are also moved to their own headers.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3be5aa3239bbff9b385ab942f749748b4d6cb352

sessiond: transition from lttng-ust to tracer agnostic API

Refactor the session daemon's user space tracer management to use the
tracer-agnostic trace hierarchy description API. Since the API
introduced under lttng::sessiond::trace is closer to idiomatic C++,
some changes are needed to make use of it.

The biggest changes make the ust_registry* structures inherit from the
trace descriptions classes (trace_class, stream_class, event_class,
clock_class). This effectively isolates the members of the
`ust_registry` structures that describe their corresponding CTF class
to a base class and leaves only the implementation guts in the
`ust_registry` objects (moved under lttng::sessiond::ust).

Since the generation of TSDL metadata directly used the lttng_ust_ctl
API, it is replaced by a new implementation that is based around a trace
class visitor that serializes the tracer agnostic trace description
objects.

The TSDL environment visitor is moved under the TSDL implementation
of the trace class visitor.

Some little changes are also made to the existing code to make it
exception-safe, as needed.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6562ef12e85afa91780337e8c6fdbb13568d9ece

sessiond: add tracer-agnostic trace hierarchy classes

The session daemon receives the fields present in events from the
instrumented applications in the form of an array of lttng_ust_ctl_field
structures and uses them directly in a number of code paths.

This makes it impossible to extend the structures which makes a number of
features harder to implement than they should be.

The session daemon also implements various CTF concepts (clock, trace,
event, stream classes) as part of various structures defined under
`ust_registry*`. This makes it hard to isolate which attributes are
"internal" and which are visible to the external world through the
traces.

Tracer-agnostic trace hierachy classes are introduced under the
lttng::sessiond::trace namespace. Those classes don't cover the full
functionality of CTF: they expose what the tracers can currently
express.

The top-level elements of the trace hierarchy -- trace, event, stream,
clock classes -- are visited using the trace_class_visitor interface.

Seperate field and type visitor interfaces are used to make it easier to
visit this subset of the trace hierarchy. This will be useful to
implement the listing of event fields through liblttng-ctl, for example.

In the short term, these classes will be used to implement the
serialization of the layout descriptions of CTF 1.8 and 2.

Change-Id: I6d99f0ec93082259bf64434c440a720ed9a49bf8
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

common: macros: missing include of pthread.h

A number of macros in this file make use of pthread APIs. However, the
header is not included.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: If13df2434bd08269984c9589ff60a2bae4484ab3

common: uuid: add `uuid_to_str` which returns an std::string

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id915ba7dbe8128d492d92faa05bbf12770a49f8d

sessiond: session registry: use pthread::lock_guard instead of raw lock

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3f5227782701a82257b710232fc02bd3c61a2e20

Tests fix: metadata event: print expected and actual event match count

The validate_metadata_event() function prints the actual event match
count twice when a test fails. Printing the expected vs actual counts
was probably the intention of the original author.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ideac2593a5d4d239ee24f98f954dddf2b5be91fa

Add lttng::locked_reference

A locked reference is a wrapper that allows functions to return a
protected/synchronized version of an object. My immediate use-case for
this helper is making it easier to call functions that return an
rcu-protected object (require the caller to hold the RCU reader lock for
the duration of its use of that object) in an exception safe manner.

As such, these functions can now return
lttng::locked_reference<MyType, lttng::urcu::unique_read_lock> which
ensures the RCU reader lock is held for as long as the object is used.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I9f4b7f918ba01491d3de14a1a570c83586f407ae

sessiond: ust: remove unused `is_sent` attribute of ust_app_channel

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: If97146367f62edf739d1228908c21346c2dae231

format: add a custom formatter for std::type_info

The name() returned by std::type_info is implementation-dependant. In
practice, it is typically the type's mangled name. For GCC and clang, it
is possible to use abi::__cxa_demangle to demangle the name at runtime
while formatting a string.

If this poses any compatibility problem on other platforms, we can
fallback to using name() directly.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ib80babe4039c91ce6fdf6d9a9442c31645a43b08

common: add macros to silence invalid offsetof warnings

Implementations are not forced to support offsetof for non-trivial types
in C++. gcc and clang both appear to support its use, but we should move
away from that. unfortunately that is not easy since offsetof is used
all over the place to use intrusive data structures.

I am unsure of the proper fix for this at the moment.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6f2cedb0da235ff3756248f370add13d46438cec

Add new exception types: communication, protocol, and invalid argument

These new exception types are useful to expess communication errors
and are used in later patches when an application doesn't honor the
liblttng-ust-ctl protocol.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: If5cd92c2f2fc31c6e68d49ade9e66f16e50394a3

Add lttng::make_unique

Add an equivalent to std::make_unique introduced in C++14.

See https://herbsutter.com/gotw/_102/ for more details.

Change-Id: I67e5b54d883e311869d7c1272f9a2905dc349212
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

consumerd: Rename global ctx variable to the_consumer_context

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Iba386af30616ac193106cb36a4ad0e9b03fb02de

sessiond: add smart pointer utils for ltt_session

Add `find_session_by_id` and `find_locked_session_by_id` which return
smart pointers to ltt_session. In both cases, the smart pointers make
use of ltt_session's underlying reference counting mechanism.

In the case of `find_locked_session_by_id`, the session that is returned
is locked; it is automatically unlocked (and a reference is released)
when the pointer goes out of scope. This makes it easier to write
exception-safe code that uses the ltt_session API.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I125dc7592b8ef2de1da645029f311bf429a21767

Add C++ wrappers for pthread mutex and rcu read lock

Add two wrappers that are similar and provide the "Mutex" named
requirements[1] around pthread_mutex_t and liburcu's RCU reader lock.

In both cases, the intention is to either use the `mutex` or `read_lock`
interface with the standard concurrency support library (e.g. std::lock,
etc.) or, more likely, use the lock_guard wrappers.

The lock_guard[2] wrappers make it easier to convert existing code to be
exception-safe and generally makes the use of those locks less
error-prone.

[1] https://en.cppreference.com/w/cpp/named_req/Mutex
[2] https://en.cppreference.com/w/cpp/thread/lock_guard

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I26cfc2e954d1d4cc1f7e0973cdcd1b9881ef181a

Add lttng::utils::time_to_iso8601_str

lttng::utils::time_to_iso8601_str implements the same formatting
as time_to_iso8601_str, but returns an std::string.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I0bd7dbbdc2c3bae6fdef7917936450953af72175

Add vendor/fmt

Add fmt 8.1.1 headers (we will use it in header-only mode). fmt is made
available under the MIT license, which is already in the LICENSES
directory.

Note that an lttng-format.hpp header is added to disable a warning which
prevents us from building with -Werror.

../../../src/vendor/fmt/format-inl.h:2457:11: error: target of initialization might be a candidate for a format attribute [-Werror=suggest-attribute=format]
 2457 |     int (*snprintf_ptr)(char*, size_t, const char*, ...) = FMT_SNPRINTF;
      |           ^~~~~~~~~~~~

The header also ensures that FMT_HEADER_ONLY is defined for all uses of
libfmt.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5696c09d6e07716b955091922bb27ce082fb2686

sessiond: Move trace_ust_clock to a clock_attributes_sample class

Move trace clock functions to a class that samples the clock's
attributes on creation. This makes it easier to implement trace format
agnostic serialization facilities in follow-up patches.

Change-Id: Id75b2c6e00779710e02691da107b2e93bf33ff12
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Change backing type of lttng_uuid to std::array

Changing the backing type of lttng_uuid to std::array allows us to
return lttng_uuid from a function. This, in return, makes it possible to
initialize const attributes from the return value of a function
returning a UUID.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie092eab4a848a41ddd9c63f779514f1e4ca2a441

sessiond: Split ust_registry_session into per-type classes

This is a preliminary refactoring step to implement support for the
conditional generation of CTF 1.8/2.0 stream description layouts.

Splitting the registry session will simplify the implementation of a
serialization visitor by segregating per-type environment attributes.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ia95dd0c67f2ff41ce4f771ce776ff84a214098b9

sessiond: Replace uses of session_trylock_list by a dedicated assert macro

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I925a2f4052149b3a9ff91a80c7541dc8ed226c70

Add basic exception types and throwing facilities

Add two LTTng-specific exception types:
  - lttng::ctl::error
  - lttng::posix_error

These types are meant to help transition from error code-based
error handling in RAII-safe functions.

lttng::ctl::error wraps `enum lttng_error_code`. It is meant to be
thrown using the `LTTNG_THROW_CTL` macro which samples the throw-site
(file name, function name, line number). This should be used only
in code paths dealing providing the liblttng-ctl interface.

It should, ultimately, be thrown in code that is specific to the
implementation of the various liblttng-ctl commands and not all over the
place since it contains very little information beyond the error code.

lttng::posix_error wraps `errno` values that are used in various places
to report errors involving (mostly) syscalls.

Over time, more specific exception types will be added.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I02e104f28dd8149aee70211b5849f3502f16d58b

.clang-format: tweak C++ style

Don't indent namespaces nor after access modifiers.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ifb67843c7c89d1f49dca9f59a76273f3b0b8fb3a

Add make_unique_wrapper()

make_unique_wrapper is intended to facilitate the use of std::unique_ptr
to wrap C-style APIs that don't provide RAII resource management facilities.

Usage example:

   // API
   struct my_c_struct {
           // ...
   };

   struct my_c_struct *create_my_c_struct(void);
   void destroy_my_c_struct(struct my_c_struct *value);

   // Creating a unique_ptr to my_c_struct.
   auto safe_c_struct =
           lttng::make_unique_wrapper<my_c_struct, destroy_my_c_struct>(
                   create_my_c_struct());

Note that this facility is intended for use in the scope of a function.
If you need to return this unique_ptr instance, you should consider writting
a proper, idiomatic, wrapper.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I429fc6f62896efb04af95fc26143096043206265

Add vendor/optional.hpp

Taken from:

https://github.com/martinmoene/optional-lite/blob/a006f229a77b3b2dacf927e4029b8c1c60c86b52/include/nonstd/optional.hpp

The BSL-1.0 license is already in the LICENSES directory, so no need to
add it.

Change-Id: I47e9a3264b771b0a6aaefc022ada9e051b6b6d20
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Clean-up: ust-consumer: replace ad-hoc channel destruction

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5018d841035eb302c0f3c092efc570b3eaa71198

Tests: test_session: include tap.h last

tap.h defines a number of macros that are very likely to clash with
other headers (e.g. ok, fail, etc.). On gcc 7.5.0, builds fail whenever
tap.h is included before an header that transitively includes
basic_ios.h.

This clash doesn't occur with more recent gcc releases (tested with 11.2
on my local machine).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I62aaa14a6d1f20c77073ab2e481eddcb28fb78f3

Fix: lttng-snapshot: use after free of max size argument

gcc 12.1.0 reports:

commands/snapshot.cpp: In function ‘int cmd_snapshot(int, const char**)’:
../../../src/common/error.hpp:139:32: error: pointer ‘max_size_arg’ may be used after ‘void free(void*)’ [-Werror=use-after-free]

free max_size_arg on both paths.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3775e835e10b364f32f4797afb9c090ac4dc133c

Fix: test: lttng kernel modules still loaded after running test_clock_override

Observed issue
==============

After running test_clock_override, some lttng modules are still loaded.

$ lsmod | ag lttng
  lttng_test             32768  0
  lttng_tracer         2326528  1 lttng_test
  lttng_statedump       749568  1 lttng_tracer
  lttng_wrapper          16384  2 lttng_statedump,lttng_tracer
  lttng_uprobes          16384  1 lttng_tracer
  lttng_kprobes          16384  1 lttng_tracer
  lttng_lib_ring_buffer    61440  1 lttng_tracer
  lttng_kretprobes       16384  1 lttng_tracer
  lttng_clock_plugin_test    16384  1
  lttng_clock            16384  2 lttng_tracer,lttng_clock_plugin_test

Cause
=====

The order in which the modules are removed is important.

In `test_clock_override_timestamp` the last `modprobe --remove order` is

  modprobe --remove lttng-clock-plugin-test lttng-clock lttng-test

While other callsites order is:

  modprobe --remove lttng-test lttng-clock-plugin-test lttng-clock

Solution
========

Use

  modprobe --remove lttng-test lttng-clock-plugin-test lttng-clock

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I528df2e3e90664433337a547a74cdbe476d4ee62

Fix: lttng: snapshot: add-output: leak of max size parameter

==1920281==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 6 byte(s) in 1 object(s) allocated from:
    #0 0x7fa95633add9 in __interceptor_malloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7fa955e90c09  (/usr/lib/libpopt.so.0+0x3c09)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I87ce90a77d9624add0cab5d3090a7e83734da7f4

Tests: fix: lttng-create: leaked command parameter

==1853705==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 3 byte(s) in 1 object(s) allocated from:
    #0 0x7fb67ee0edd9 in __interceptor_malloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7fb67e964c09  (/usr/lib/libpopt.so.0+0x3c09)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I2f3346157cb26de6712c6e6ebd5fafa6b51fac08

Fix: sessiond: rotation trigger leak

==1801304==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 224 byte(s) in 2 object(s) allocated from:
    #0 0x7fe0f4e73fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x559fbeb64175 in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x559fbeb6a291 in lttng_trigger* zmalloc<lttng_trigger>() ../../src/common/macros.hpp:89
    #3 0x559fbeb64aa6 in lttng_trigger_create /home/jgalar/EfficiOS/src/lttng-tools/src/common/trigger.cpp:58
    #4 0x559fbe9dc417 in subscribe_session_consumed_size_rotation(ltt_session*, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/rotate.cpp:87
    #5 0x559fbe995d6f in cmd_rotation_set_schedule(ltt_session*, bool, lttng_rotation_schedule_type, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/cmd.cpp:5993
    #6 0x559fbe9fe559 in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2246
    #7 0x559fbea01378 in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2624
    #8 0x559fbe9ea642 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:68
    #9 0x7fe0f44935c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

Indirect leak of 208 byte(s) in 2 object(s) allocated from:
    #0 0x7fe0f4e73fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x559fbeb16e21 in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x559fbeb16e31 in lttng_action_notify* zmalloc<lttng_action_notify>() ../../src/common/macros.hpp:89
    #3 0x559fbeb168a0 in lttng_action_notify_create actions/notify.cpp:135
    #4 0x559fbe9dc34b in subscribe_session_consumed_size_rotation(ltt_session*, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/rotate.cpp:80
    #5 0x559fbe995d6f in cmd_rotation_set_schedule(ltt_session*, bool, lttng_rotation_schedule_type, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/cmd.cpp:5993
    #6 0x559fbe9fe559 in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2246
    #7 0x559fbea01378 in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2624
    #8 0x559fbe9ea642 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:68
    #9 0x7fe0f44935c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

Indirect leak of 160 byte(s) in 2 object(s) allocated from:
    #0 0x7fe0f4e73fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x559fbeb3d7a1 in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x559fbeb3fa35 in lttng_condition_session_consumed_size* zmalloc<lttng_condition_session_consumed_size>() ../../src/common/macros.hpp:89
    #3 0x559fbeb3e6fd in lttng_condition_session_consumed_size_create conditions/session-consumed-size.cpp:206
    #4 0x559fbe9dc0f1 in subscribe_session_consumed_size_rotation(ltt_session*, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/rotate.cpp:54
    #5 0x559fbe995d6f in cmd_rotation_set_schedule(ltt_session*, bool, lttng_rotation_schedule_type, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/cmd.cpp:5993
    #6 0x559fbe9fe559 in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2246
    #7 0x559fbea01378 in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2624
    #8 0x559fbe9ea642 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:68
    #9 0x7fe0f44935c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

Indirect leak of 112 byte(s) in 2 object(s) allocated from:
    #0 0x7fe0f4e73fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x559fbeb242ad in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x559fbeb27062 in zmalloc<(anonymous namespace)::lttng_rate_policy_every_n> ../../src/common/macros.hpp:89
    #3 0x559fbeb25e9f in lttng_rate_policy_every_n_create actions/rate-policy.cpp:492
    #4 0x559fbeb168b9 in lttng_action_notify_create actions/notify.cpp:141
    #5 0x559fbe9dc34b in subscribe_session_consumed_size_rotation(ltt_session*, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/rotate.cpp:80
    #6 0x559fbe995d6f in cmd_rotation_set_schedule(ltt_session*, bool, lttng_rotation_schedule_type, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/cmd.cpp:5993
    #7 0x559fbe9fe559 in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2246
    #8 0x559fbea01378 in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2624
    #9 0x559fbe9ea642 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:68
    #10 0x7fe0f44935c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

Indirect leak of 34 byte(s) in 2 object(s) allocated from:
    #0 0x7fe0f4e19319 in __interceptor_strdup /usr/src/debug/gcc/libsanitizer/asan/asan_interceptors.cpp:454
    #1 0x559fbeb3f603 in lttng_condition_session_consumed_size_set_session_name conditions/session-consumed-size.cpp:442
    #2 0x559fbe9dc2c4 in subscribe_session_consumed_size_rotation(ltt_session*, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/rotate.cpp:71
    #3 0x559fbe995d6f in cmd_rotation_set_schedule(ltt_session*, bool, lttng_rotation_schedule_type, unsigned long, notification_thread_handle*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/cmd.cpp:5993
    #4 0x559fbe9fe559 in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2246
    #5 0x559fbea01378 in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2624
    #6 0x559fbe9ea642 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:68
    #7 0x7fe0f44935c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

The rotation trigger of a session (used for size-based rotations) is
never cleaned-up. It is now cleaned up every time its condition is
hit and whenever the session is destroyed.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5a89341535f87b7851b548ded9838c18bd1ccb95

Tests: fix: schedule api: leak of rotation schedule list

==1769573==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7fef37a29fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7fef37792f2f in zmalloc_internal ../../../src/common/macros.hpp:60
    #2 0x7fef3779573a in lttng_rotation_schedules* zmalloc<lttng_rotation_schedules>() ../../../src/common/macros.hpp:89
    #3 0x7fef377947cc in lttng_rotation_schedules_create /home/jgalar/EfficiOS/src/lttng-tools/src/lib/lttng-ctl/rotate.cpp:353
    #4 0x7fef37794aa0 in get_schedules /home/jgalar/EfficiOS/src/lttng-tools/src/lib/lttng-ctl/rotate.cpp:392
    #5 0x7fef377956dc in lttng_session_list_rotation_schedules /home/jgalar/EfficiOS/src/lttng-tools/src/lib/lttng-ctl/rotate.cpp:665
    #6 0x5646131713f2 in test_add_list_remove_schedule /home/jgalar/EfficiOS/src/lttng-tools/tests/regression/tools/rotation/schedule_api.c:252
    #7 0x56461317157b in test_add_list_remove_size_schedule /home/jgalar/EfficiOS/src/lttng-tools/tests/regression/tools/rotation/schedule_api.c:270
    #8 0x564613171680 in main /home/jgalar/EfficiOS/src/lttng-tools/tests/regression/tools/rotation/schedule_api.c:307
    #9 0x7fef373ae30f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I9b7eb537d158791db76f9a7676ffeb5d4a1f2203

Fix: lttng: enable-rotation: leak of command parameter

==1759491==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 6 byte(s) in 1 object(s) allocated from:
    #0 0x7fdbdc94add9 in __interceptor_malloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7fdbdc4a0c09  (/usr/lib/libpopt.so.0+0x3c09)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I29cc6ec4390e71829107f309f162247b9be2868c

Fix: lttng: track: leaked command parameter

==1676099==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 5 byte(s) in 1 object(s) allocated from:
    #0 0x7f19429d9dd9 in __interceptor_malloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7f19425342ad in poptGetNextOpt (/usr/lib/libpopt.so.0+0x82ad)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ibafcaf42ad4f842b3fa74cf91dc5ecc8acb3487d

Fix: lttng: add-trigger: leak of parser context on capture

==1501334==ERROR: LeakSanitizer: detected memory leaks

Indirect leak of 16386 byte(s) in 1 object(s) allocated from:
    #0 0x7f95efc3cdd9 in __interceptor_malloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55acb0681ed3 in lttng_filter_yyalloc(unsigned long, void*) filter/filter-lexer.cpp:2511
    #2 0x55acb067f2f2 in lttng_filter_yy_create_buffer(_IO_FILE*, int, void*) filter/filter-lexer.cpp:1895
    #3 0x55acb067ea44 in yyrestart(_IO_FILE*, void*) filter/filter-lexer.cpp:1824
    #4 0x55acb0649a43 in filter_parser_ctx_alloc(_IO_FILE*) filter/filter-parser.ypp:271
    #5 0x55acb0649e7f in filter_parser_ctx_create_from_filter_expression(char const*, filter_parser_ctx**) filter/filter-parser.ypp:332
    #6 0x55acb058ee89 in parse_event_rule commands/add_trigger.cpp:783
    #7 0x55acb05920c0 in handle_condition_event commands/add_trigger.cpp:1361
    #8 0x55acb0592739 in parse_condition commands/add_trigger.cpp:1457
    #9 0x55acb0596b56 in cmd_add_trigger(int, char const**) commands/add_trigger.cpp:2304
    #10 0x55acb05a5b80 in handle_command /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:238
    #11 0x55acb05a6643 in parse_args /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:427
    #12 0x55acb05a694a in main /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:476
    #13 0x7f95ef28730f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6fa21e7d066e0cf48afc3f91ceefbfd19c6b86fd

Tests: fix: leak of trigger in trigger listing tests

==1480456==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x7fdb9260cfb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7fdb9242348d in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x7fdb924295a9 in lttng_trigger* zmalloc<lttng_trigger>() ../../src/common/macros.hpp:89
    #3 0x7fdb92423dbe in lttng_trigger_create /home/jgalar/EfficiOS/src/lttng-tools/src/common/trigger.cpp:58
    #4 0x56304832331f in register_trigger /home/jgalar/EfficiOS/src/lttng-tools/tests/regression/tools/trigger/utils/register-some-triggers.cpp:24
    #5 0x5630483233f1 in register_trigger_action_list_notify /home/jgalar/EfficiOS/src/lttng-tools/tests/regression/tools/trigger/utils/register-some-triggers.cpp:46
    #6 0x5630483239a0 in test_session_rotation_conditions /home/jgalar/EfficiOS/src/lttng-tools/tests/regression/tools/trigger/utils/register-some-triggers.cpp:246
    #7 0x563048323d4d in main /home/jgalar/EfficiOS/src/lttng-tools/tests/regression/tools/trigger/utils/register-some-triggers.cpp:309
    #8 0x7fdb91c6630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie163989a70f65f9c2c4e93c36cc9fc6ba6bdeeb5

Fix: action error query: leak of action path

==1429021==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7fe305f031b2 in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
    #1 0x559f1b022238 in lttng_dynamic_buffer_set_capacity(lttng_dynamic_buffer*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:159
    #2 0x559f1b021d9f in lttng_dynamic_buffer_append(lttng_dynamic_buffer*, void const*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:52
    #3 0x559f1b02144a in lttng_dynamic_array_add_element(lttng_dynamic_array*, void const*) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-array.cpp:58
    #4 0x559f1b07d07b in lttng_action_path_copy(lttng_action_path const*, lttng_action_path*) actions/path.cpp:116
    #5 0x559f1b02383f in lttng_error_query_action_create /home/jgalar/EfficiOS/src/lttng-tools/src/common/error-query.cpp:232
    #6 0x559f1b02760e in lttng_error_query_create_from_payload(lttng_payload_view*, lttng_error_query**) /home/jgalar/EfficiOS/src/lttng-tools/src/common/error-query.cpp:911
    #7 0x559f1af5c361 in receive_lttng_error_query /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:740
    #8 0x559f1af64eba in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2336
    #9 0x559f1af67378 in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2624
    #10 0x559f1af50642 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:68
    #11 0x7fe3055225c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I7a6f7d2a9746124581eebf30877466f16db67a6b

Fix: lttng: enable-channel: leak of popt arguments

==1245463==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 5 byte(s) in 1 object(s) allocated from:
    #0 0x7fe7c494fdd9 in __interceptor_malloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7fe7c44a5c09  (/usr/lib/libpopt.so.0+0x3c09)

Arguments obtained with poptGetOptArg() must be free'd.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5a65ca6fbaa18f7717ea918a5bc7f42daeb1009a

Tests: clean-up: rate policy: remove stale comment

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Idd030c765b0a4afa2d13ff015a17bd52493204a6

Tests: fix: leak of rate policy in rate policy unit tests

==1198508==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x7f8b62634fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x557871869adb in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x55787186c8a0 in zmalloc<(anonymous namespace)::lttng_rate_policy_once_after_n> ../../src/common/macros.hpp:89
    #3 0x55787186c173 in lttng_rate_policy_once_after_n_create actions/rate-policy.cpp:707
    #4 0x55787186a368 in lttng_rate_policy_once_after_n_create_from_payload actions/rate-policy.cpp:183
    #5 0x55787186ad02 in lttng_rate_policy_create_from_payload(lttng_payload_view*, lttng_rate_policy**) actions/rate-policy.cpp:287
    #6 0x557871865b5b in test_rate_policy_once_after_n /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_rate_policy.cpp:231
    #7 0x557871865dc9 in main /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_rate_policy.cpp:250
    #8 0x7f8b61c7130f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x7f8b62634fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x557871869adb in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x55787186c890 in zmalloc<(anonymous namespace)::lttng_rate_policy_every_n> ../../src/common/macros.hpp:89
    #3 0x55787186b6cd in lttng_rate_policy_every_n_create actions/rate-policy.cpp:492
    #4 0x55787186a699 in lttng_rate_policy_every_n_create_from_payload actions/rate-policy.cpp:220
    #5 0x55787186ad02 in lttng_rate_policy_create_from_payload(lttng_payload_view*, lttng_rate_policy**) actions/rate-policy.cpp:287
    #6 0x557871864cae in test_rate_policy_every_n /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_rate_policy.cpp:122
    #7 0x557871865dc4 in main /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_rate_policy.cpp:249
    #8 0x7f8b61c7130f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

SUMMARY: AddressSanitizer: 112 byte(s) leaked in 2 allocation(s).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3a9b4d99e93f355ddb8623a289f8397907486ab0

Tests: fix: leak of payload in serdes test of log level rule

==1190137==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7f40a9d4c1b2 in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
    #1 0x55ab716e1def in lttng_dynamic_buffer_set_capacity(lttng_dynamic_buffer*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:159
    #2 0x55ab716e1956 in lttng_dynamic_buffer_append(lttng_dynamic_buffer*, void const*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:52
    #3 0x55ab716ca64e in lttng_log_level_rule_serialize(lttng_log_level_rule const*, lttng_payload*) /home/jgalar/EfficiOS/src/lttng-tools/src/common/log-level-rule.cpp:177
    #4 0x55ab716c760f in test_log_level_rule_serialize_deserialize /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_log_level_rule.cpp:60
    #5 0x55ab716c8457 in test_log_level_rule_at_least_as_severe_as /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_log_level_rule.cpp:177
    #6 0x55ab716c84d3 in main /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_log_level_rule.cpp:185
    #7 0x7f40a938830f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7f40a9d4c1b2 in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
    #1 0x55ab716e1def in lttng_dynamic_buffer_set_capacity(lttng_dynamic_buffer*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:159
    #2 0x55ab716e1956 in lttng_dynamic_buffer_append(lttng_dynamic_buffer*, void const*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:52
    #3 0x55ab716ca64e in lttng_log_level_rule_serialize(lttng_log_level_rule const*, lttng_payload*) /home/jgalar/EfficiOS/src/lttng-tools/src/common/log-level-rule.cpp:177
    #4 0x55ab716c760f in test_log_level_rule_serialize_deserialize /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_log_level_rule.cpp:60
    #5 0x55ab716c8135 in test_log_level_rule_exactly /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_log_level_rule.cpp:154
    #6 0x55ab716c84ce in main /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_log_level_rule.cpp:184
    #7 0x7f40a938830f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I2d1eafabbd5c101c188bad8a2137615b29c0ef68

Tests: fix: leak of some attributes of ltt_ust_session

==1175545==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8696 byte(s) in 1 object(s) allocated from:
    #0 0x7efed0f39fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x55707ddc6004 in zmalloc_internal ../../../src/common/macros.hpp:60
    #2 0x55707ddceb17 in ltt_ust_session* zmalloc<ltt_ust_session>() ../../../src/common/macros.hpp:89
    #3 0x55707ddc81e7 in trace_ust_create_session(unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/trace-ust.cpp:274
    #4 0x55707ddc2bea in test_create_one_ust_session /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_ust_data.cpp:63
    #5 0x55707ddc4941 in main /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_ust_data.cpp:283
    #6 0x7efed04f930f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Indirect leak of 24672 byte(s) in 1 object(s) allocated from:
    #0 0x7efed0f39fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x55707dee4ec1 in zmalloc_internal ../../../src/common/macros.hpp:60
    #2 0x55707def774e in consumer_output* zmalloc<consumer_output>() ../../../src/common/macros.hpp:89
    #3 0x55707dee90df in consumer_create_output(consumer_dst_type) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/consumer.cpp:523
    #4 0x55707ddc8821 in trace_ust_create_session(unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/trace-ust.cpp:321
    #5 0x55707ddc2bea in test_create_one_ust_session /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_ust_data.cpp:63
    #6 0x55707ddc4941 in main /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_ust_data.cpp:283
    #7 0x7efed04f930f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Indirect leak of 1024 byte(s) in 1 object(s) allocated from:
    #0 0x7efed0f39fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7efed0bf985f in alloc_split_items_count /home/jgalar/EfficiOS/src/userspace-rcu/src/rculfhash.c:688
    #2 0x7efed0bf985f in _cds_lfht_new /home/jgalar/EfficiOS/src/userspace-rcu/src/rculfhash.c:1642

Indirect leak of 656 byte(s) in 1 object(s) allocated from:
    #0 0x7efed0f39fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7efed0bfac68 in __default_alloc_cds_lfht ../src/rculfhash-internal.h:172
    #2 0x7efed0bfac68 in alloc_cds_lfht /home/jgalar/EfficiOS/src/userspace-rcu/src/rculfhash-mm-order.c:81

Indirect leak of 48 byte(s) in 2 object(s) allocated from:
    #0 0x7efed0f39fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7efed0bfabd4 in cds_lfht_alloc_bucket_table /home/jgalar/EfficiOS/src/userspace-rcu/src/rculfhash-mm-order.c:35
    #2 0x7efed0bfabd4 in cds_lfht_alloc_bucket_table /home/jgalar/EfficiOS/src/userspace-rcu/src/rculfhash-mm-order.c:28

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7efed0f39fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x55707de3a9af in zmalloc_internal ../../src/common/macros.hpp:60
    #2 0x55707de3a9bf in lttng_ht* zmalloc<lttng_ht>() ../../src/common/macros.hpp:89
    #3 0x55707de38461 in lttng_ht_new(unsigned long, lttng_ht_type) hashtable/hashtable.cpp:113
    #4 0x55707dee9340 in consumer_create_output(consumer_dst_type) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/consumer.cpp:535
    #5 0x55707ddc8821 in trace_ust_create_session(unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/trace-ust.cpp:321
    #6 0x55707ddc2bea in test_create_one_ust_session /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_ust_data.cpp:63
    #7 0x55707ddc4941 in main /home/jgalar/EfficiOS/src/lttng-tools/tests/unit/test_ust_data.cpp:283
    #8 0x7efed04f930f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7efed0f39fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7efed0bfac15 in cds_lfht_alloc_bucket_table /home/jgalar/EfficiOS/src/userspace-rcu/src/rculfhash-mm-order.c:31

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ib2ad82a197f2a4ccb86ae5799c1d93ff059888e3

Fix: liblttng-ctl: leak of payload on field listing

LeakSanitizer reports the following leak:

==974957==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7fdb86fcd1b2 in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
    #1 0x7fdb86d7c296 in lttng_dynamic_buffer_set_capacity(lttng_dynamic_buffer*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:159
    #2 0x7fdb86d7c060 in lttng_dynamic_buffer_set_size(lttng_dynamic_buffer*, unsigned long) /home/jgalar/EfficiOS/src/lttng-tools/src/common/dynamic-buffer.cpp:112
    #3 0x7fdb86d2589a in recv_payload_sessiond /home/jgalar/EfficiOS/src/lttng-tools/src/lib/lttng-ctl/lttng-ctl.cpp:230
    #4 0x7fdb86d26fa5 in lttng_ctl_ask_sessiond_payload(lttng_payload_view*, lttng_payload*) /home/jgalar/EfficiOS/src/lttng-tools/src/lib/lttng-ctl/lttng-ctl.cpp:662
    #5 0x7fdb86d2cd8d in lttng_list_tracepoint_fields /home/jgalar/EfficiOS/src/lttng-tools/src/lib/lttng-ctl/lttng-ctl.cpp:1767
    #6 0x56481623cb4c in list_ust_event_fields commands/list.cpp:850
    #7 0x5648162448d9 in cmd_list(int, char const**) commands/list.cpp:2394
    #8 0x56481628fb3e in handle_command /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:238
    #9 0x564816290601 in parse_args /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:427
    #10 0x564816290908 in main /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng/lttng.cpp:476
    #11 0x7fdb8661730f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).

The session daemon's reply is indeed never released in
lttng_list_tracepoint_fields.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Idd244b52a69f3b74e5c131c1c36c6ee6d76f4285

Fix: sessiond: ODR violation results in memory corruption

Issue observed
==============

Address sanitizer reports the following invalid accesses while running
the test_mi test.

❯ ASAN_OPTIONS=detect_odr_violation=0 lttng-sessiond
=================================================================
==289173==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400000e280 at pc 0x55cbbe35e2e0 bp 0x7f01672f1550 sp 0x7f01672f1540
WRITE of size 4 at 0x60400000e280 thread T13
    #0 0x55cbbe35e2df in mark_thread_as_ready /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/manage-consumer.cpp:32
    #1 0x55cbbe360160 in thread_consumer_management /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/manage-consumer.cpp:267
    #2 0x55cbbe336ac4 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:66
    #3 0x7f01729c15c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)
    #4 0x7f0172a46583 in __clone (/usr/lib/libc.so.6+0x112583)

0x60400000e280 is located 8 bytes to the right of 40-byte region [0x60400000e250,0x60400000e278)
allocated by thread T7 here:
    #0 0x7f01733b1fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x55cbbe33adf3 in zmalloc_internal ../../../src/common/macros.hpp:60
    #2 0x55cbbe33ae03 in thread_notifiers* zmalloc<thread_notifiers>() ../../../src/common/macros.hpp:89
    #3 0x55cbbe3617f9 in launch_consumer_management_thread(consumer_data*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/manage-consumer.cpp:440
    #4 0x55cbbe33cf49 in spawn_consumer_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:188
    #5 0x55cbbe33f7cf in start_consumerd /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:394
    #6 0x55cbbe345713 in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:1277
    #7 0x55cbbe34d74b in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2622
    #8 0x55cbbe336ac4 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:66
    #9 0x7f01729c15c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

Thread T13 created by T7 here:
    #0 0x7f0173353eb7 in __interceptor_pthread_create /usr/src/debug/gcc/libsanitizer/asan/asan_interceptors.cpp:216
    #1 0x55cbbe336f9e in lttng_thread_create(char const*, void* (*)(void*), bool (*)(void*), void (*)(void*), void*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:106
    #2 0x55cbbe3618cc in launch_consumer_management_thread(consumer_data*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/manage-consumer.cpp:453
    #3 0x55cbbe33cf49 in spawn_consumer_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:188
    #4 0x55cbbe33f7cf in start_consumerd /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:394
    #5 0x55cbbe345713 in process_client_msg /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:1277
    #6 0x55cbbe34d74b in thread_manage_clients /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2622
    #7 0x55cbbe336ac4 in launch_thread /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:66
    #8 0x7f01729c15c1 in start_thread (/usr/lib/libc.so.6+0x8d5c1)

Thread T7 created by T0 here:
    #0 0x7f0173353eb7 in __interceptor_pthread_create /usr/src/debug/gcc/libsanitizer/asan/asan_interceptors.cpp:216
    #1 0x55cbbe336f9e in lttng_thread_create(char const*, void* (*)(void*), bool (*)(void*), void (*)(void*), void*) /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/thread.cpp:106
    #2 0x55cbbe34eebf in launch_client_thread() /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/client.cpp:2756
    #3 0x55cbbe27f31a in main /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/main.cpp:1838
    #4 0x7f017296130f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/jgalar/EfficiOS/src/lttng-tools/src/bin/lttng-sessiond/manage-consumer.cpp:32 in mark_thread_as_ready
Shadow bytes around the buggy address:
  0x0c087fff9c00: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
  0x0c087fff9c10: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
  0x0c087fff9c20: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
  0x0c087fff9c30: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
  0x0c087fff9c40: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 fa
=>0x0c087fff9c50:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==289173==ABORTING

Cause
=====

The start functions of the various worker threads of the session daemon
are implemented in separate translation units (TU). To make use of the
lttng_thread API, they all define different control structures to
control their shutdown.

Those structures are all named 'thread_notifiers' and are all allocated
using zmalloc<>. The various instances of zmalloc<thread_notifiers> all
end up having the same mangled name (e.g.
_Z7zmallocI16thread_notifiersEPT_v).

At link time, only one instance of zmalloc<thread_notifiers> is kept.
Since those structures all have different layout/sizes, this is
problematic. However, it is an acceptable behaviour according to the ODR
[1].

I first considered making the various memory allocation functions in
macros.hpp 'static' which results in each TU holding the appropriate
specialization of the various functions. While this works, it doesn't
make us ODR-compliant. To make a long story short, a program defining
multiple types sharing the same name, in the same namespace, is
ill-formed.

Another concern is that marking all templated free-functions as static
will eventually result in code bloat.

Solution
========

All structures defined in TUs (but not in a header) are placed in
unnamed namespaces (also called anonymous namespaces) [2].

This results in separate copies of the templated functions being
generated when specialized using a structure in an anonymous
namespace (e.g. _Z7zmallocIN12_GLOBAL__N_116thread_notifiersEEPT_v).

We could have renamed the various `thread_notifiers` structures to give
them different names. However, I found those are not the only structures
sharing a name in different TUs. For instance, the same problem applies
to `struct lttng_index` (index in a stream, index in a map).

I propose we systematically namespace structures defined in TUs in the
future.

This will also save us trouble if those POD structures eventually become
non-POD: we would experience the same "clashes" if those structures had
constructors, for example.

References
==========

[1] https://en.cppreference.com/w/cpp/language/definition
[2] https://en.cppreference.com/w/cpp/language/namespace

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I867e5a287ad8cf3ada617335bc1a80b800bf0833

Fix: liblttng-ctl: non-packed structure used for tracker serialization

Using unpacked structures in liblttng-ctl's protocol can cause issues
when mixing sessiond and client of different bitness. In this specific
case I doubt it causes a problem, but it could rightfully do on some
architectures.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie17096a55a4b7508c604e184cae877b83df6e451

Fix: sessiond: assert on empty payload when handling client out event

Observed issue
==============

When servicing a large number of tracer notifications and sending
notifications to clients, the session daemon occasionally hits
an assertion:

  #4  0x00007fb224d7d116 in __assert_fail () from /usr/lib/libc.so.6
  #5  0x000056038b2fe4d7 in client_flush_outgoing_queue (client=0x7fb21400c3b0) at notification-thread-events.cpp:3586
  #6  0x000056038b2ff819 in handle_notification_thread_client_out (state=0x7fb221974090, socket=77) at notification-thread-events.cpp:4104
  #7  0x000056038b2f3d77 in thread_notification (data=0x56038cc7fe90) at notification-thread.cpp:763
  #8  0x000056038b30ca7d in launch_thread (data=0x56038cc7e220) at thread.cpp:66
  #9  0x00007fb224dcf5c2 in start_thread () from /usr/lib/libc.so.6
  #10 0x00007fb224e54584 in clone () from /usr/lib/libc.so.6

Cause
=====

A client "out" event can be received when no payload is left
to send under some circumstances.

Many threads can flush a client's outgoing queue and, if they
had to queue their message (socket was full), will use the
"communication update" command to signal the (e)poll thread
to monitor for space being made available in the socket.

Commands are sent over an internal pipe serviced by the same
thread as the client sockets.

When space is made available in the socket, there is a race
between the (e)poll thread and the other threads that may
wish to use the client's socket to flush its outgoing queue.

A non-(e)poll thread may attempt (and succeed) in flushing
the queue before the (e)poll thread gets a chance to service
the client's "out" event.

In this situation, the (e)poll thread processing the client
out event will see an empty payload: there is nothing to do.

Solution
========

The (e)poll thread can simply ignore the "client out" event
when an empty payload is seen.

There is also no need to update the transmission status as
the other thread has already enqueued a "communication
update" command to do so.

Known drawbacks
===============

None.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I8a181bea1e37e8e14cc67b624b76d139b488eded

Bump minimum kernel version to 2.6.30 to use EFD_SEMAPHORE

The bump in the kernel version allows the use of EFD_SEMAPHORE for
eventfd.

Adjust the README.md to reflect this. No need to provide direct
instruction for older kernel. We leave the '--disable-epoll' switch
available and the code behind it simply because other platform might not
have epoll available.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id512f018c5394c9cc699e19c3d5a0d753e56414b

Fix: Revert of 814b4934e2604a419bcb8eec57c0450dbb47e2c3

Observed issue
==============

During high throughput event notification generation scenarios the
following deadlock happens:

 Thread 14 (Thread 0x7f74b4ff9700 (LWP 76062)):
 #0  __lll_lock_wait (futex=futex@entry=0x56408765dde8, private=0) at lowlevellock.c:52
 #1  0x00007f74c941a0a3 in __GI___pthread_mutex_lock (mutex=0x56408765dde8) at ../nptl/pthread_mutex_lock.c:80
 #2  0x000056408704b207 in run_command_wait (handle=0x56408765ddd0, cmd=0x7f74b4ff7f70) at notification-thread-commands.cpp:31
 #3  0x000056408704bcef in notification_thread_command_remove_tracer_event_source (handle=0x56408765ddd0, tracer_event_source_fd=54) at notification-thread-commands.cpp:319
 #4  0x000056408708a0c1 in delete_ust_app (app=0x7f749c000bf0) at ust-app.cpp:1059
 #5  0x000056408708a511 in delete_ust_app_rcu (head=0x7f749c000ca0) at ust-app.cpp:1122
 #6  0x00007f74c988b4a7 in call_rcu_thread (arg=0x7f74b8004a80) at ../src/urcu-call-rcu-impl.h:369
 #7  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #8  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 13 (Thread 0x7f74b57fa700 (LWP 76047)):
 #0  0x00007f74c933a49e in epoll_wait (epfd=48, events=0x7f74a4000b60, maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7f74b57f9240, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x00005640870abb65 in thread_agent_management (data=0x56408765f0b0) at agent-thread.cpp:424
 #3  0x0000564087062b1a in launch_thread (data=0x56408765f150) at thread.cpp:66
 #4  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #5  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 12 (Thread 0x7f74b5ffb700 (LWP 76046)):                                                                                                                                       [630/709]
 #0  0x00007f74c933a49e in epoll_wait (epfd=47, events=0x7f74a0000b60, maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7f74b5ffa170, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x00005640870a4095 in thread_application_notification (data=0x56408765ee40) at notify-apps.cpp:78
 #3  0x0000564087062b1a in launch_thread (data=0x56408765eed0) at thread.cpp:66
 #4  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #5  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 11 (Thread 0x7f74b67fc700 (LWP 76045)):
 #0  0x00007f74c933a49e in epoll_wait (epfd=44, events=0x7f74ac000b60, maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7f74b67fb170, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x00005640870723db in thread_application_management (data=0x56408765ebd0) at manage-apps.cpp:93
 #3  0x0000564087062b1a in launch_thread (data=0x56408765ec60) at thread.cpp:66
 #4  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #5  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 10 (Thread 0x7f74b6ffd700 (LWP 76044)):
 #0  0x00007f74c933a49e in epoll_wait (epfd=39, events=0x7f74a8000b60, maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7f74b6ffc130, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x0000564087070a27 in thread_application_registration (data=0x56408765e940) at register.cpp:214
 #3  0x0000564087062b1a in launch_thread (data=0x56408765e9f0) at thread.cpp:66
 #4  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #5  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 9 (Thread 0x7f74b77fe700 (LWP 76043)):                                                                                                                                        [654/709]
 #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
 #1  0x00005640870c8e25 in futex (uaddr=0x5640871e2800 <ust_cmd_queue>, op=0, val=-1, timeout=0x0, uaddr2=0x0, val3=0) at /home/joraj/lttng/master/install/include/urcu/futex.h:72
 #2  0x00005640870c8e6d in futex_async (uaddr=0x5640871e2800 <ust_cmd_queue>, op=0, val=-1, timeout=0x0, uaddr2=0x0, val3=0) at /home/joraj/lttng/master/install/include/urcu/futex.h:104
 #3  0x00005640870c939a in futex_nto1_wait (futex=0x5640871e2800 <ust_cmd_queue>) at futex.cpp:77
 #4  0x000056408706f2af in thread_dispatch_ust_registration (data=0x56408765e740) at dispatch.cpp:453
 #5  0x0000564087062b1a in launch_thread (data=0x56408765e760) at thread.cpp:66
 #6  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #7  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 8 (Thread 0x7f74b7fff700 (LWP 76042)):
 #0  0x00007f74c933a49e in epoll_wait (epfd=33, events=0x7f74b0000b60, maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7f74b7ffad40, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x000056408706c424 in thread_manage_clients (data=0x56408765e4f0) at client.cpp:2528
 #3  0x0000564087062b1a in launch_thread (data=0x56408765e560) at thread.cpp:66
 #4  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #5  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 7 (Thread 0x7f74c4b8f700 (LWP 76041)):                                                                                                                                        [672/709]
 #0  0x00007f74c933a49e in epoll_wait (epfd=31, events=0x7f74bc000b60, maxevents=3, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7f74c4b8e240, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x000056408705f2b6 in thread_rotation (data=0x56408765e280) at rotation-thread.cpp:804
 #3  0x0000564087062b1a in launch_thread (data=0x56408765e310) at thread.cpp:66
 #4  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #5  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 6 (Thread 0x7f74c5390700 (LWP 76040)):
 #0  0x00007f74c925f1d2 in __GI___sigtimedwait (set=0x7f74c538f090, info=0x7f74c538f110, timeout=0x0) at ../sysdeps/unix/sysv/linux/sigtimedwait.c:29
 #1  0x000056408706138a in thread_timer (data=0x7ffc1fcbe3f0) at timer.cpp:359
 #2  0x0000564087062b1a in launch_thread (data=0x56408765e0a0) at thread.cpp:66
 #3  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #4  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 5 (Thread 0x7f74c5b91700 (LWP 76039)):
 #0  __libc_write (nbytes=8, buf=0x7f74c5b8fc88, fd=24) at ../sysdeps/unix/sysv/linux/write.c:26
 #1  __libc_write (fd=24, buf=0x7f74c5b8fc88, nbytes=8) at ../sysdeps/unix/sysv/linux/write.c:24
 #2  0x00005640870eeb4f in lttng_write (fd=24, buf=0x7f74c5b8fc88, count=8) at readwrite.cpp:77
 #3  0x000056408704b535 in run_command_no_wait (handle=0x56408765ddd0, in_cmd=0x7f74c5b8fdf0) at notification-thread-commands.cpp:92
 #4  0x000056408704bf49 in notification_thread_client_communication_update (handle=0x56408765ddd0, id=2, transmission_status=CLIENT_TRANSMISSION_STATUS_QUEUED) at notification-thread-command
 #5  0x000056408707bc62 in client_handle_transmission_status (client=0x7f74b80050d0, status=CLIENT_TRANSMISSION_STATUS_QUEUED, user_data=0x7f74b8004410) at action-executor.cpp:258
 #6  0x0000564087057525 in notification_client_list_send_evaluation (client_list=0x7f74b8004df0, trigger=0x7f74b0001030, evaluation=0x7f74b815d1d0, source_object_creds=0x0, client_report=0x5
 #7  0x000056408707bce9 in action_executor_notify_handler (executor=0x7f74b8004410, work_item=0x7f74b815d430, item=0x7f74b80e48e0) at action-executor.cpp:269
 #8  0x000056408707dd6d in action_executor_generic_handler (executor=0x7f74b8004410, work_item=0x7f74b815d430, item=0x7f74b80e48e0) at action-executor.cpp:670
 #9  0x000056408707df01 in action_work_item_execute (executor=0x7f74b8004410, work_item=0x7f74b815d430) at action-executor.cpp:689

 #10 0x000056408707e525 in action_executor_thread (_data=0x7f74b8004410) at action-executor.cpp:771                                                                                   [698/709]
 #11 0x0000564087062b1a in launch_thread (data=0x7f74b80044b0) at thread.cpp:66
 #12 0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #13 0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 4 (Thread 0x7f74c6392700 (LWP 76038)):
 #0  __lll_lock_wait (futex=futex@entry=0x56408765dde8, private=0) at lowlevellock.c:52
 #1  0x00007f74c941a0a3 in __GI___pthread_mutex_lock (mutex=0x56408765dde8) at ../nptl/pthread_mutex_lock.c:80
 #2  0x0000564087053c89 in handle_notification_thread_command (handle=0x56408765ddd0, state=0x7f74c63911b0) at notification-thread-events.cpp:3142
 #3  0x000056408704ac81 in thread_notification (data=0x56408765ddd0) at notification-thread.cpp:715
 #4  0x0000564087062b1a in launch_thread (data=0x56408765dec0) at thread.cpp:66
 #5  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #run_command_no_wait6  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 3 (Thread 0x7f74c6b93700 (LWP 76037)):
 #0  0x00007f74c933a49e in epoll_wait (epfd=21, events=0x7f74c0000b60, maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7f74c6b92170, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x000056408706400a in thread_manage_health (data=0x56408765db50) at health.cpp:140
 #3  0x0000564087062b1a in launch_thread (data=0x56408765dbf0) at thread.cpp:66
 #4  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #5  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 2 (Thread 0x7f74c7394700 (LWP 76036)):
 #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
 #1  0x00007f74c987d238 in futex (uaddr=0x564087659b10, op=0, val=-1, timeout=0x0, uaddr2=0x0, val3=0) at ../include/urcu/futex.h:72
 #2  futex_async (uaddr=0x564087659b10, op=0, val=-1, timeout=0x0, uaddr2=0x0, val3=0) at ../include/urcu/futex.h:104
 #3  futex_wait (futex=0x564087659b10) at workqueue.c:136
 #4  0x00007f74c987ced2 in workqueue_thread (arg=0x564087659ad0) at workqueue.c:237
 #5  0x00007f74c9417609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #6  0x00007f74c933a163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 1 (Thread 0x7f74c73cd300 (LWP 76034)):
 #0  0x00007f74c933a49e in epoll_wait (epfd=50, events=0x564087666880, maxevents=1, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
 #1  0x00005640870eafa6 in compat_epoll_wait (events=0x7ffc1fcbe280, timeout=-1, interruptible=false) at compat/poll.cpp:280
 #2  0x0000564087062244 in sessiond_wait_for_quit_pipe (timeout_ms=-1) at thread-utils.cpp:83
 #3  0x00005640870127dc in main (argc=1, argv=0x7ffc1fcbe668) at main.cpp:1921

Cause
=====

The event_pipe used to notify the notification poll loop is full and the
lttng_write call blocks with the locks for both the client and the
cmd_queue held.

Solution
========

Go back to using eventfd but without the use of EFD_SEMAPHORE (linux
2.6.30) to continue supporting kernel between 2.6.27 and 2.6.29.

The EFD_SEMAPHORE is emulated with a read, decrement, write as explained
by the initial committer of EFD_SEMAPHORE [1].

Known drawbacks
=========

This does not solve the actual block+lock problem but simply push it
back further. The lttng_write on the eventfd can block when reaching
UINT64_MAX. This would represent, at 1 command queued per ns (which is
ridiculous), ~584 years of queueing without a dequeue operation.

Reference
=======
[1] https://lwn.net/Articles/318151/

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie749c4169708f57463fe3cfab2366f1015bae4e0

Build fix: missing type traits on gcc < 5.0

gcc versions before 5.0 lack some type traits defined in C++11. Since in
this instance we use the trait to prevent misuses of certain functions
to statically assert at build time and not to generate different code
based on this property, it is preferable to simply set value to true and
allow the code to compile. Anyone using a contemporary compiler will
catch the error.

I have not replaced the type trait checks with macros using gcc-specific
checks (__has_trivial_copy(), for example) since their semantics diverge
subtly from the standard and their use could introduce bugs.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id57cc1cff67847c725f75eb3404443732de1c531

Build fix: poll compatibility mode: zmalloc prototype changed

The build fails on platforms that don't support the epoll system
call (or when building with --disable-epoll on Linux):

  compat/poll.cpp:458:35: error: no matching function for call to 'zmalloc'
          wait->events = (struct pollfd *) zmalloc(size * sizeof(struct pollfd));
                                           ^~~~~~~
  ./macros.hpp:85:4: note: candidate template ignored: couldn't infer template argument 'T'
  T *zmalloc(size_t size)
     ^
  ./macros.hpp:74:4: note: candidate function template not viable: requires 0 arguments, but 1 was provided
  T *zmalloc()
     ^
  compat/poll.cpp:466:38: error: no matching function for call to 'zmalloc'
          current->events = (struct pollfd *) zmalloc(size * sizeof(struct pollfd));
                                              ^~~~~~~
  ./macros.hpp:85:4: note: candidate template ignored: couldn't infer template argument 'T'
  T *zmalloc(size_t size)
     ^
  ./macros.hpp:74:4: note: candidate function template not viable: requires 0 arguments, but 1 was provided
  T *zmalloc()

Replace the uses of "old style" malloc with the new type-safe
function introduced recently.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ib1660f6a548c155f021843b7476d5d64c06c6e5a

Fix: sessiond: inverted condition checking for empty hash table

I inverted a condition while reformating 2a6ebf6bd. This reverts the
condition to the intention of the original author. Mea culpa.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I8c39a89f430dbb4a0f1e385b3b8e4788f188a468

Fix: notification: kernel: consumption of event notification stalls

Observed issue
==============

Using:

 lttng add-trigger --condition event-rule-matches --type kernel:tracepoint --name "sched_waking" --capture comm --action notify

The sessiond receives multiple event notifications from the kernel event
source then stop receiving despite the kernel event source buffer
being full.

Cause
=====

It turns out that the kernel event source, when reaching near the end of
its buffer capacity, raises the POLLPRI [1] flag and not the POLLIN
flag.

Solution
========

lttng-modules stretches a bit the usage of POLLPRI as defined by the man
page (man 2 poll):

 There is some exceptional condition on the  file  descriptor. Possibilities
 include:

 *  There is out-of-band data on a TCP socket (see tcp(7)).

 *  A  pseudoterminal  master  in  packet  mode has seen a state change on the
    slave (see ioctl_tty(2)).

 *  A cgroup.events file has been modified (see cgroups(7)).

Still, even if lttng-modules changes how it does things, lttng-tools
needs to support other lttng-modules versions.

Thus, add LPOLLPRI (EPOLLPRI/POLLPRI) to the event mask when dealing
with notification event sources.

Note
=====

In the future, during the poll loop we could also prioritize
event sources in POLLPRI 'state'.

Known drawbacks
=========

None.

References
==========

[1] https://github.com/lttng/lttng-modules/blob/c312bda00d2dc10ce5f6c1189acbefee5c6c8c6c/src/lttng-abi.c#L1169

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ieb428ef1037c8eb197b489a38a1ae5216ac63d4b

Fix: notification: assert on len > 0 for dropped notification message

Observed issue
==============

Using the notification client from
doc/examples/trigger-condition-event-matches/notification-client.cpp, an
assert is hit when the notification subsystem is under load.

 #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 #1  0x00007f69eab58859 in __GI_abort () at abort.c:79
 #2  0x00007f69eab58729 in __assert_fail_base (fmt=0x7f69eacee588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f69eae1d5dd "len > 0", file=0x7f69eae1d5cb "unix.cpp", line=179, function=<optimized out>) at assert.c:92
 #3  0x00007f69eab6a006 in __GI___assert_fail (assertion=0x7f69eae1d5dd "len > 0", file=0x7f69eae1d5cb "unix.cpp", line=179, function=0x7f69eae1d598 "ssize_t lttcomm_recv_unix_sock(int, void*, size_t)") at assert.c:101
 #4  0x00007f69eadd5fe6 in lttcomm_recv_unix_sock (sock=3, buf=0x55da9ecd5f89, len=0) at unix.cpp:179
 #5  0x00007f69ead7df3f in receive_message (channel=0x55da9ecd6ee0) at channel.cpp:64
 #6  0x00007f69ead7e478 in lttng_notification_channel_get_next_notification (channel=0x55da9ecd6ee0, _notification=0x7ffdefed2570) at channel.cpp:279
 #7  0x000055da9e0e742f in main (argc=2, argv=0x7ffdefed2698) at notification-client.cpp:506

 (gdb) frame
 #5  0x00007f69ead7df3f in receive_message (channel=0x55da9ecd6ee0) at channel.cpp:64
 64              ret = lttcomm_recv_unix_sock(channel->socket,

 (gdb) print msg
 $2 = {type = 5 '\005', size = 0, fds = 0, payload = 0x7ffdefed24a8 ""}

The msg type 5 is
`LTTNG_NOTIFICATION_CHANNEL_MESSAGE_TYPE_NOTIFICATION_DROPPED`

Cause
=====

The msg portion of a
`LTTNG_NOTIFICATION_CHANNEL_MESSAGE_TYPE_NOTIFICATION_DROPPED` is indeed
zero. There is no extra payload.

Solution
========

When the msg size is zero, skip the 'payload' reception phase.

Known drawbacks
=========

None.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ibabb922d0e410c9902414a5eabbe04738861d772

Fix: example: print_notification is called on status all returned status

The notification should only be printed for
`LTTNG_NOTIFICATION_CHANNEL_STATUS_OK`.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5534406d8fbd5c0fff7013fda6335d54bef071a2

Fix: sessiond: assertion hit in ltt_sessions_ht_empty

Observed issue
==============

Scenario:

gdb lttng-sessiond
  set non-stop
  break rotation-thread.cpp:584
  ^ simulates a slow rotation thread or not scheduled thread.

lttng create test1
lttng enable-event -u -a
lttng start test1
lttng create test2
lttng enable-event -u -a
lttng start test2
lttng destroy test1
   This will hang on rotation pending checks on the CLI side.

In another shell:

lttng destroy test2
   This will hang on rotation pending checks on the CLI side.

Back to gdb
   thread 7
   continue

Results in:

 #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 #1  0x00007ffff786c859 in __GI_abort () at abort.c:79
 #2  0x00007ffff786c729 in __assert_fail_base (fmt=0x7ffff7a02588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5555556bb148 "count == lttng_ht_get_count(ltt_sessions_ht_by_name)", file=0x5555556bae9f "session.cpp", line=395, function=<optimized out>) at assert.c:92
 #3  0x00007ffff787e006 in __GI___assert_fail (assertion=0x5555556bb148 "count == lttng_ht_get_count(ltt_sessions_ht_by_name)", file=0x5555556bae9f "session.cpp", line=395, function=0x5555556bb129 "int ltt_sessions_ht_empty()") at assert.c:101
 #4  0x0000555555586d59 in ltt_sessions_ht_empty () at session.cpp:395
 #5  0x0000555555586e53 in del_session_ht (ls=0x7fffdc000c30) at session.cpp:418
 #6  0x0000555555588a95 in session_release (ref=0x7fffdc001e50) at session.cpp:999
 #7  0x000055555558620f in urcu_ref_put (ref=0x7fffdc001e50, release=0x5555555886eb <session_release(urcu_ref*)>) at /home/joraj/lttng/master/install/include/urcu/ref.h:68
 #8  0x0000555555588c8f in session_put (session=0x7fffdc000c30) at session.cpp:1048
 #9  0x00005555555bf995 in handle_job_queue (handle=0x55555575d260, state=0x7fffeeffc240, queue=0x555555758960) at rotation-thread.cpp:612
 #10 0x00005555555c05da in thread_rotation (data=0x55555575d260) at rotation-thread.cpp:847
 #11 0x00005555555c3b1c in launch_thread (data=0x55555575d2f0) at thread.cpp:66
 #12 0x00007ffff7a46609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #13 0x00007ffff7969163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Other scenarios can lead to a similar backtrace when using the
`--no-wait` lttng destroy option.

Cause
=====

Since ed41e5709047ef545aa28082416e641e003b45e0 [1], hash table removal
for the session object for the `ltt_sessions_ht_by_name` and
`ltt_sessions_ht_by_name` are "decoupled". Removal from
`ltt_sessions_ht_by_name` is done early in `session_destroy()` while
removal from `ltt_sessions_ht_by_id` is done during `session_release` when
the last reference of a session object is released.

This can leads to `imbalances` between the size of the two hash tables
when multiple sessions are at play.

Solution
========

Rework `ltt_sessions_ht_empty()` to exit early when
`ltt_sessions_ht_by_id` is not empty. Perform a sanity check on
`ltt_sessions_ht_by_name` only when `ltt_sessions_ht_by_id` is empty.

Note
========

Ideally both hash tables' lifetime would be managed separately but it
seems easier in term of initialization to bundle them together for now
considering the limited scope of the `ltt_sessions_ht_by_name` hash
table.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I66c459f80298f929add703ac977cccd1da6dd556

Fix: tests: missing _GNU_SOURCE for F_GETPIPE_SZ

Per man 2 fcntl:

  F_GETOWN_EX,  F_SETOWN_EX,  F_SETPIPE_SZ,  F_GETPIPE_SZ,  F_GETSIG,  F_SETSIG,
  F_NOTIFY,   F_GETLEASE,   and  F_SETLEASE  are  Linux-specific.   (Define  the
  _GNU_SOURCE macro to obtain these definitions.)

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I2b61dfb79ffa384dc2bab56cd3510ddc6ae21e85

Fix: compat: 'LTTNG_UST_ABI_PROCNAME_LEN' is undeclared

Observed issue
==============

On old systems, the `lttng_pthread_setname_np` function fallsback to
using the compat prctl version. In that context,
`LTTNG_UST_ABI_PROCNAME_LEN` is indeed not declared.

Solution
========

Use `LTTNG_PTHREAD_NAMELEN`. This mimics what is done in other versions
of `lttng_pthread_setname_np`.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I73956cacd7b1e9400881b17b1cd89db2530d3a00

common: prevent using memset on non-POD types

While converting some code to use C++ constructs, it can be easy to
forget to change some spot that uses memset to initialize or move the
object. Add a templated deleted declaration to prevent using memset on
types that aren't POD.

For example, if I make lttng_ust_event non-POD, in
src/bin/lttng-sessiond/trace-ust.h, I get this error:

      CXX      save.lo
    /home/simark/src/lttng-tools/src/bin/lttng-sessiond/save.cpp: In function ‘int save_agent_events(config_writer*, agent*)’:
    /home/simark/src/lttng-tools/src/bin/lttng-sessiond/save.cpp:1246:23: error: use of deleted function ‘void* memset(T*, int, size_t) [with T = ltt_ust_event; <template-parameter-1-2> = void; size_t = long unsigned int]’
     1246 |                 memset(&fake_event, 0, sizeof(fake_event));
          |                 ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In file included from /home/simark/src/lttng-tools/src/common/defaults.h:14,
                     from /home/simark/src/lttng-tools/src/bin/lttng-sessiond/save.cpp:15:
    /home/simark/src/lttng-tools/src/common/macros.h:128:7: note: declared here
      128 | void *memset(T *s, int c, size_t n) = delete;
          |       ^~~~~~

Note: I tried applying this to memcpy as well, but Clang gave me some
troubles with its -Waddress-of-packed-member diagnostic, so I gave up.

Change-Id: Id55735db15901c6fc5d58e9b6b6b689733302398
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Tests: validate_xml: leak of xml document instance

`doc` is never free'd when validating an XML.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ia0b541963350aeb6610382fd3226ffd37ab4847e

Add type-checked versions of allocation and deallocations functions

A common mistake when porting things from C to C++ is to use malloc for
types that have a on-trivial constructor (and to not call the
constructor explicitly either). For example:

struct foo {
std::vector<int> field;
};

foo *f = (foo *) zmalloc(sizeof(*f));

This allocates a `foo` without calling the constructor, leaving it in an
invalid state. Same idea when free-ing with free something that has a
non-trivial destructor.

To avoid this, I suggest adding templated allocation functions that we
will use throughout, that verify if the given type is safe to malloc
(and generate a compilation failure if not). The existing code barely
needs changes. For example:

- (foo *) zmalloc(sizeof(*f))
+ zmalloc<foo>()

For simplicity I propose that as soon as a type is non-POD
(std::is_pod<T>::value is false), we prevent using malloc/free on it. It
would be ok in theory to allocate such a type with malloc and free with
free, but call the constructor (using placement-new) and destructor
explicitly, but I don't see why we would want to do that. It might also
be technically more correct to use a combination of
std::is_trivially_constructible and std::is_trivially_destructible
(std::is_pod being not fine-grained enough), but using std::is_pod just
keeps things simpler.

This patch introduces the following templated allocation functions:

1. zmalloc<T>()
2. zmalloc<T>(size)
3. malloc<T>()
4. malloc<T>(size)
5. calloc<T>(nmemb)

1. Allocate one T, zero-initialized
2. Allocate a buffer of size `size`, zero-initialized, this is used when
   the caller calculates the size to allocate, like when using flexible
   array members
3. Same as 1, but without the zero-initialization
4. Same as 2, but without the zero-initialization
5. Allocate an array of `nmemb` elements of type T, zero-initialized

For the de-allocation side, add templated `free` function declaration
that uses std::enable_if (SFINAE) to declare a deleted prototype if the
type T isn't safe to free (causing a compilation error).

There are a lot of places where we pass pointers to void to free. These
can't be checked, as we don't know what type of object the pointer
really points to. We could forbid that and fix all callers to pass a
typed pointer, but that seems a bit too much to chew for the moment. So
for now, simply accept that freeing pointers to void won't be checked.
It's a best effort.

As an example, if I add an explicit constructor to type ctf_trace (in
src/bin/lttng-relayd/ctf-trace.h), I get the following errors with
clang. For the allocation:

/home/simark/src/lttng-tools/src/common/macros.h:57:2: error: static_assert failed due to requirement 'std::is_pod<ctf_trace>::value' "type is POD"
static_assert (std::is_pod<T>::value, "type is POD");
^              ~~~~~~~~~~~~~~~~~~~~~
/home/simark/src/lttng-tools/src/bin/lttng-relayd/ctf-trace.cpp:84:10: note: in instantiation of function template specialization 'zmalloc<ctf_trace>' requested here
trace = zmalloc<ctf_trace>();
^

For the de-allocation:

/home/simark/src/lttng-tools/src/bin/lttng-relayd/ctf-trace.cpp:29:2: error: call to deleted function 'free'
free(trace);
^~~~
/home/simark/src/lttng-tools/src/common/macros.h:125:6: note: candidate function [with T = ctf_trace, $1 = void] has been explicitly deleted
void free(T *p) = delete;
     ^
/usr/include/stdlib.h:565:13: note: candidate function
extern void free (void *__ptr) __THROW;
    ^

Change-Id: I246a9113d08fa36b81a49137f4e80a5e808de913
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

sessiond: document RCU locking assumption during channel metadata statedump

The rcu read lock must be held by the caller during a call to
ust_metadata_channel_statedump. An assertion and a comment are added.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ia57a140d51470cc43cf62d36c9b4b552e1c17191