Fix: common: hide shm* util symbols

Internal symbols that are part of libcommon must be marked as "hidden".
Otherwise, the symbols are exported as part of liblttng-ctl.so.

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

Fix: mark channel as disabled even if the session is inactive

Observed issue
==============
When the session is stopped, disable-channel commands are no-op.

The following commands reproduce the issue:
  lttng create
  lttng enable-event -u -a
  lttng start
  sleep 4
  lttng stop

  lttng disable-channel -u channel0
  sleep 10
  lttng start
  sleep 4
  lttng stop

  lttng view

Note that the sleep command there are to give the UST application time
to produce events.

Even after disabling the channel, we can see that events are still
traced.

This is due to the fact that the `channel_ust_disable()` function
returns early if the session is inactive and omits to set the channel as
disabled.

Proposed fix
============
Move this following line before the check:
uchan->enabled = 0;

Test
====
Add a test case to exercise this exact scenario.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I9660064ac6eb99f2aea8851dc98a94cfc1b810e6

Fix: condition: buffer-usage: use double instead of fixed point

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

When running the test_notification_ust_buffer_usage test on x86
(32 bit), the session daemon and test client both crash. The session
daemon dies while attempting to lock a NULL client list during the
execution of an enqueued action in the action executor.

See the following backtrace:

 #0  0xf7c6c756 in __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:67
 #1  0x565afe96 in notification_client_list_send_evaluation (client_list=0x0, trigger=0xf0f225e0, evaluation=0xf330c830, source_object_creds=0xf330e5cc, client_report=0x565cf81b <client_handle_transmission_status>, user_data=0xf330c320) at notification-thread-events.c:4372
 #2  0x565cfb41 in action_executor_notify_handler (executor=0xf330c320, work_item=0xf330e5b0, item=0xf330c7b0) at action-executor.c:269
 #3  0x565d1a58 in action_executor_generic_handler (executor=0xf330c320, work_item=0xf330e5b0, item=0xf330c7b0) at action-executor.c:696
 #4  0x565d1b7f in action_work_item_execute (executor=0xf330c320, work_item=0xf330e5b0) at action-executor.c:715
 #5  0x565d212f in action_executor_thread (_data=0xf330c320) at action-executor.c:797
 #6  0x565b9d0e in launch_thread (data=0xf330c390) at thread.c:66
 #7  0xf7c69fd2 in start_thread (arg=<optimized out>) at pthread_create.c:486
 #8  0xf7b7f6d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108

This crash causes an assertion to fail in the test client; checking for
data pending was not expected to return a negative value. In this case,
the negative return value is justified as it is -LTTNG_ERR_NO_SESSIOND.

Cause
=====

Equipped with coffee, a debugger, and a healthy dose of print
statements, it appeared that the following was taking place:

- Register a trigger (T1): high buffer usage (0.99) -> notify (succeeds)
- Subscribe to high buffer usage (0.99) notifications (succeeds)
- Subscribe to high buffer usage (0.99) notifications
  (fails duplicate, expected)
- Unregister trigger (fails unexpectedly)
- Notification client destroys its channel, causing the condition to be
  unsubscribed-from

- Another test registers a trigger (T2): high buffer usage (0.90) ->
  notify (succeeds)
- Session daemon evaluates a channel sample against T1's condition,
  which evaluates to true and produces an "evaluation" to send to
  clients
- The client list associated to T1's condition is not found (but this
  isn't checked)
- An action executor work item is queued to run T1's actions (notify),
  but without a client list, resulting in the crash when it is executed.

We could confirm that the client list associated to T1's condition was
created and never destroyed making the failure to find it rather
puzzling.

It turns out that the hash of T1's condition did not match the hash of
the client list's condition. This is unexpected as both conditions are
copies of one another.

It turns out that, on x86, the scheme being used to transmit the
condition's buffer usage threshold floating point value is not compiled
to numerically stable code. Serializing such a buffer condition and
creating it from the resulting payload in a loop showed that the
threshold value gradually drifted. This isn't the case on the other
architectures we support.

On x86-64, gcc makes use of SSE instructions to perform the conversion
to an integral value (with double precision). However, on x86, it makes
use of the x87 fpu stack instructions which carry 80-bit of precision
internally, resulting in a loss of precision as the value is
transformed, back and forth, between 80-bit to double precision
representations.

Solution
========

Since conditions are not carried between hosts (only between clients
and the session daemon), a fixed-point conversion scheme is unnecessary.
The 'double' value provided by the client is carried directly which
bypasses the problem completely.

Drawbacks
=========

None.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie524e7362626406327f4f56e1dba5c8cf469df31

Tests: notification: fail on trigger unregistration failure

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

Update version to v2.13.0-rc1

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

Set the 2.13 release codename and description

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

Tests: fix: test_notification_notifier_discarded_count missing renames

Some options of lttng-add-trigger were renamed without adapting the
test since that part is only ran when destructive tests are enabled.

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

Docs: lttng-add-trigger and lttng-remove-trigger refer to owner-id

The proper name of the option is --owner-uid.

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

Fix: tests: test case using old condition syntax

This commit also changes "on-event" -> "event-rule-matches"

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I0b9ff1302ca5a3e8bbdddc8a626890c527dcbd59

lttng-add-trigger(1): clarify the `--rate-policy` documentation

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6144521f3186e33c52d7ac20b64cf3e8f7663a55

Update some manual pages for LTTng-tools 2.13

This patch updates some manual pages for LTTng-tools 2.13. A few pages
still remain to be updated, a task which is reserved for a subsequent
patch.

This patch:

* Improves the consistency of the the command descriptions in
  `configure.ac`.

* Adds `common-help-option.txt` which is the description of any
  `--help` option.

* Adds `common-intro.txt` which is a common description introduction for
  the top-level manual pages.

* Adds `lttng-event-rule.7.txt` which describes the common way to
  specify an event rule on the command-line.

  lttng-event-rule(7) has a "Migration from a recording event rule
  specification" section with a table which shows the relationship
  between lttng-enable-event(1) command-line arguments and
  lttng-event-rule(7) options.

  As of this patch, only `lttng-add-trigger.1.txt` references it,
  for the `event-rule-matches` trigger condition.

  `Makefile.am` is also updated to build and include manual pages of
  section 7.

* Updates existing manual pages to:

  * Have a style and voice which is more consistent with the
    LTTng Documentation (website) for 2.13.

  * Fix various terminology ambiguities.

  * Use more textual variables and lists to explain more complex logic
    and processes.

  More specifically:

  lttng-add-context(1):
      Specify that this command adds context fields to be recorded
      to the event records of one or more channels.

      In other words, this is a recording-related command. You don't
      need to use it to access context fields with the filter expression
      of an event rule, for example.

  lttng-add-trigger(1):
      * Update the "NAME" section.

      * Add internal option links where missing.

      * Improve the description.

        Add links to the lttng-remove-trigger(1) and
        lttng-list-triggers(1) manual pages and explain what those
        commands are used for.

        Use "condition specifier" and "action specifier" terms to
        describe those groups of options.

        For condition and action specifiers, use localized synopses.

        For action specifiers, add links to the corresponding LTTng
        command manual pages.

      * Document the `--owner-id` option.

      * Group option descriptions.

      * Use "name" instead of "ID".

      * Refer to the new lttng-event-rule(7) manual page.

      * Remove the "no context field" limitation for `ERSPEC`.

      * Fix verse blocks nested in lists.

  lttng-create(1):
      * Add more documentation about tracing sessions.

      * Specify that the `create` command can spawn a session daemon.

      * Add the "Current tracing session" section to explain this
        concept and where it applies.

      * Clarify the "URL format" section.

  lttng-disable-event(1):
      Explain how this command can only find recording event rules
      to disable by instrumentation point type and event name condition.

  lttng-enable-event(1):
      I more or less completely rewrote this page.

      The document now clearly explains the related core concepts, shows
      the explicit and implicit conditions of a recording event rule,
      has one section for each condition explaining how an event can
      satisfy it, and more.

      The synopsis is more accurate.

      I added an "Event record name" section to indicate what's the name
      of a matched event depending on the instrumentation point type and
      some command-line arguments.

      I also added an "Enable a disabled recording event rule" section
      to explain how the `enable-event` command enables existing,
      disabled events.

      This manual page now documents all the options, even if they're
      the default, as defaults may change in the future.

      The new lttng-event-rule(7) manual page is based on this one, but
      with its own ways to specify event rule conditions.

  lttng-remove-trigger(1):
      * Use "name" instead of "ID".
      * Use `--owner-id` instead of `--user-id`.

  lttng-sessiond(8):
      * Explain what an LTTng session daemon does.

      * Clarify everything related to the tracing group and root
        session daemon.

      * Add a "Daemon configuration" section which explains the
        INI configuration files and the `--config` option.

      * Make the "Tracing session configuration loading" section
        (renamed) much more straightforward, with less text.

      * Specify that the `--daemonize` and `--background` options
        make `lttng-sessiond` only exit when the daemon is ready to
        receive client commands.

  lttng-set-session(1):
      List which commands rely on the current tracing session
      concept.

  lttng(1):
      * Add a "Session daemon connection" section which shows how the
        `lttng` tool (or any LTTng tracing control application) connects
        to a session daemon (user-specific vs. root session daemon).

      * Use tables to list the available commands.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6b98f4907d94763f3bfcb6576e4add9cfc59a2e3

.gitignore: add register-some-triggers trigger test utility

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

Fix: event-expr.c: use-after-free and NULL ptr deref in error path

use-after-free
==============
The following functions are affected:
  `lttng_event_expr_app_specific_context_field_create()`, and
  `lttng_event_expr_array_field_element_create()`.

In one error path we call `lttng_event_expr_destroy()` with the
`&expr->parent` pointer (which is dynamically allocated) and this
function then calls free() on that pointer. Right after that function
call we return the pointer that was just freed.

Fix that by adding a `ret_parent_expr` pointer that is set to NULL on
the error path;

Null pointer dereference
========================
The following functions are affected:
  `lttng_event_expr_app_specific_context_field_create()`,
  `lttng_event_expr_array_field_element_create()`, and
  `create_field_event_expr()`.

We dereference a NULL pointer if the argument sanity check fails.

Fix that by checking if `expr` is non-null before dereferencing it.

Found with scan-build.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5fdde462d7345d0dae7ecd2e4f46473a92cd11a9

Adapt to namespaced liblttng-ust-ctl symbols

The liblttng-ust ABI bump gave us the opportunity to namespace all
public symbols under the 'lttng_ust_' prefix. All of liblttng-ust-ctl
public symbols were renamed from 'ustctl_' to 'lttng_ust_ctl_'. Adapt
the tools codebase for this API change.

Depends-on: lttng-ust: Ic2b9da019e7776b24b98824ae63d16b86c5a5742

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

Cleanup: ust-app.c: Dead assignment

Found using scan-build.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I8920ee21d8202e9b94b95f517c8e1fbe8c9224a0

Fix: tests: gen-ust-events-ns: Uninitialized argument value

If both `if (snprintf(...` of the `get_ns_inum()` function fail, the
function will not uninitialize the `ns_inum` output parameter and still
return 0. Leading to the argument `ns1` of debug_printf() being used
uninitialized.

Reported-by: scan-build.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I47286312095ca0f6a889eb0faa93661f92156ec1

Fix: consumerd: strlen called on uninitialized path

closed_trace_chunk_path is uninitialized when relayd_id != 0.

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

Fix: sessiond: notification: leak of condition on duplicate subscription

An lttng_condition is leaked when a notification channel client attempts
to subscribe to a condition she is already subscribed to.

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

Fix: action executor: deadlock on session_list_lock

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

A dead lock is observed during the start-stop test suite for triggers.

Cause
=====

A start session action is executed by the action executor, the
`cmd_start_trace` function is called and effectively holds the
`session_list_lock.`. During `cmd_start_trace` a call to
`notification_thread_command_add_channel` is performed to inform the
notification thread of the new channel presence.

At the same time, a tracer event notification is received by the
notification thread. The actions are queued up and the sample of the
session id take place and a call to `session_lock_list` is performed and
blocks on the lock operation.

The notification thread wait on the `session_list_lock` and the
`session_list_lock` holder, the action executor, waits on the completion
of a command the be run by the notification thread: deadlock.

The backtrace:

 Thread 6 (Thread 0x7f831c8a6700 (LWP 3046458)):
 #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
 #1  0x000000000053b852 in futex (uaddr=0x7f831c8a45e0, op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0) at /home/joraj/lttng/master/install/include/urcu/futex.h:72
 #2  0x000000000053b4f9 in futex_noasync (uaddr=0x7f831c8a45e0, op=0, val=0, timeout=0x0, uaddr2=0x0, val3=0) at /home/joraj/lttng/master/install/include/urcu/futex.h:81
 #3  0x000000000053af10 in lttng_waiter_wait (waiter=0x7f831c8a45d8) at waiter.c:55
 #4  0x000000000046b0f2 in run_command_wait (handle=0xe60520, cmd=0x7f831c8a4588) at notification-thread-commands.c:49
 #5  0x000000000046b270 in notification_thread_command_add_channel (handle=0xe60520, session_name=0x7f8300006c30 "my_triggered_session", uid=1000, gid=1000, channel_name=0x7f82dc00be04 "channel0", key=1, domain=LTTNG_DOMAIN_UST, capacity=2097152) at notification-thread-commands.c:184
 #6  0x00000000004c7f65 in create_channel_per_uid (app=0x7f82d8000bf0, usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, ua_chan=0x7f82dc00bde0) at ust-app.c:3360
 #7  0x00000000004c6f98 in ust_app_channel_send (app=0x7f82d8000bf0, usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, ua_chan=0x7f82dc00bde0) at ust-app.c:3514
 #8  0x00000000004c6bde in ust_app_channel_create (usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, uchan=0x7f8300005a90, app=0x7f82d8000bf0, _ua_chan=0x7f831c8a48b0) at ust-app.c:4771
 #9  0x00000000004c6968 in find_or_create_ust_app_channel (usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, app=0x7f82d8000bf0, uchan=0x7f8300005a90, ua_chan=0x7f831c8a48b0) at ust-app.c:5610
 #10 0x00000000004c4f09 in ust_app_synchronize_all_channels (usess=0x7f8300000bb0, ua_sess=0x7f82dc002600, app=0x7f82d8000bf0) at ust-app.c:5820
 #11 0x00000000004b958c in ust_app_synchronize (usess=0x7f8300000bb0, app=0x7f82d8000bf0) at ust-app.c:5886
 #12 0x00000000004b8500 in ust_app_global_update (usess=0x7f8300000bb0, app=0x7f82d8000bf0) at ust-app.c:5960
 #13 0x00000000004b7ec2 in ust_app_start_trace_all (usess=0x7f8300000bb0) at ust-app.c:5520
 #14 0x0000000000444e86 in cmd_start_trace (session=0x7f8300006c30) at cmd.c:2707
 #15 0x00000000004a5af9 in action_executor_start_session_handler (executor=0x7f8314004410, work_item=0x7f8314005100, item=0x7f83140050b0) at action-executor.c:342
 #16 0x00000000004a537f in action_executor_generic_handler (executor=0x7f8314004410, work_item=0x7f8314005100, item=0x7f83140050b0) at action-executor.c:696
 #17 0x00000000004a4dbc in action_work_item_execute (executor=0x7f8314004410, work_item=0x7f8314005100) at action-executor.c:715
 #18 0x00000000004a37e6 in action_executor_thread (_data=0x7f8314004410) at action-executor.c:797
 #19 0x0000000000486193 in launch_thread (data=0x7f83140044b0) at thread.c:66
 #20 0x00007f8320b60609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #21 0x00007f8320a87293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 5 (Thread 0x7f831d0a7700 (LWP 3046457)):
 #0  __lll_lock_wait (futex=futex@entry=0x5e1c10 <ltt_session_list>, private=0) at lowlevellock.c:52
 #1  0x00007f8320b630a3 in __GI___pthread_mutex_lock (mutex=0x5e1c10 <ltt_session_list>) at ../nptl/pthread_mutex_lock.c:80
 #2  0x00000000004378c3 in session_lock_list () at session.c:156
 #3  0x00000000004a871c in add_action_to_subitem_array (action=0x7f830001a730, subitems=0x7f83140051d0) at action-executor.c:1081
 #4  0x00000000004a8578 in add_action_to_subitem_array (action=0x7f830001a620, subitems=0x7f83140051d0) at action-executor.c:1025
 #5  0x00000000004a4922 in populate_subitem_array_from_trigger (trigger=0x7f830001a950, subitems=0x7f83140051d0) at action-executor.c:1116
 #6  0x00000000004a416e in action_executor_enqueue_trigger (executor=0x7f8314004410, trigger=0x7f830001a950, evaluation=0x7f8314005190, object_creds=0x0, client_list=0x7f8314004980) at action-executor.c:924
 #7  0x0000000000479481 in dispatch_one_event_notifier_notification (state=0x7f831d0a63e8, notification=0x7f8314005160) at notification-thread-events.c:4613
 #8  0x0000000000472324 in handle_one_event_notifier_notification (state=0x7f831d0a63e8, pipe=65, domain=LTTNG_DOMAIN_UST) at notification-thread-events.c:4702
 #9  0x0000000000472271 in handle_notification_thread_event_notification (state=0x7f831d0a63e8, pipe=65, domain=LTTNG_DOMAIN_UST) at notification-thread-events.c:4717
 #10 0x00000000004695a3 in handle_event_notification_pipe (event_source_fd=65, domain=LTTNG_DOMAIN_UST, revents=1, state=0x7f831d0a63e8) at notification-thread.c:591
 #11 0x000000000046849b in thread_notification (data=0xe60520) at notification-thread.c:727
 #12 0x0000000000486193 in launch_thread (data=0xe60610) at thread.c:66
 #13 0x00007f8320b60609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 #14 0x00007f8320a87293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Solution
========

Instead of using session_find_by_name() which requires the
`session_list_lock`, we introduce `sample_session_id_by_name` that uses
a urcu backed data structure. This allows the sampling of the session
id without holding the session list lock. We accept the small window
where a session object is still accessible but concretely not valid
since the actual execution context will be validated at the moment of
execution. The execution side already handles the possibility that the
session is removed at that point or is not the same session. The
execution side acquires the session_list_lock for validation.

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: I5ad2c57acc0d03d2814dda59f8ecf2d831fd961e

lttng add-trigger: replace --exclude-names with --exclude-name

Implement the proposal to make the --exclude-names option singular. The
user can specify it multiple times to specify multiple exclusions,
rather than specifying a comma-separated list.

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

sessiond: refcount `ust_error_accounting_entry`

Keep a reference count of the `ust_error_accounting_entry` to reclaim
memory and cleanup handles as we go.

Triggers on a sessiond target all applications regardless of the UID of
both the trigger and the application. This means that whenever a new UST
counter is created for a UID, we need to keep it around as long as there
is 1. an application from that UID, or 2. an event notifier registered.

This commit achieves that by keeping a count of the registered event
notifiers. If the count is above zero, we keep a reference on every UID
entries. When the count reaches zero, we put that reference on every
entries.

The event notifier count is guarded by a mutex since it's accessed by
both the notification thread and UST registration thread.

Here is the pseudo code for the relevant error accounting events:
App registration:
  lookup entry for application UID in hashtable
  if found:
    get a reference on that existing entry
  else:
    create a new entry for that UID
    get a reference on that new entry
    if event_notifier_count > 0:
      get an extra reference on the behalf of the event notifiers

Event notifier registration:
  increment event_notifier_count
  if event_notifier_count == 1:
    get a reference on all existing UID entries

App unregistration:
  put reference on application UID entry

Event notifier unregistration:
  decrement event_notifier_count
  if event_notifier_count == 0:
    put ref on all existing UID entries

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I74667d30a5b6975bad7975b82f6819e263199cd0

action list: missing renames from previous name "group"

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

Fix: error-query: uninitialized action_index value

action_index will be used uninitialized if the user passes an action
that is not part of the trigger (an API use error).

CID 1452662 (#2 of 2): Uninitialized scalar variable (UNINIT)
14. uninit_use: Using uninitialized value action_index.is_set.

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

Fix: sessiond: leak of config_path on duplicate --config option

1452207 Resource leak

The system resource will not be reclaimed and reused, reducing the
future availability of the resource.

CID 1452373 (#3 of 3): Resource leak (RESOURCE_LEAK)
26. overwrite_var: Overwriting config_path in config_path =
utils_expand_path(optarg) leaks the storage that config_path points to.

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

Fix: tests: base notification client: unchecked sscanf return value

CID 1407934 (#2 of 2): Unchecked return value (CHECKED_RETURN)
8. check_return: Calling sscanf without checking return value (as is
done elsewhere 17 out of 19 times).

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

Fix: argpar: Error out when passing an argument to long option that takes no argument

If the user defines a long option `--foo` and passes `--foo=arg`, the
current behavior is that the option foo is recognized and the argument
is ignored.  Change that to be an error.

It is currently not possible to pass arguments to short options using an
equal sign, so this doesn't apply to short options.

Equivalent accepted change in argpar: https://review.lttng.org/c/argpar/+/5361

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

Clean-up: sessiond: identation fix

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

Fix: tests: health thread stall: only stop consumerd when required

Since a0f8e3109, stop_lttng_consumerd will report a failure when
there is no consumer daemon to kill. This fix ensures it is only
invoked for tests that launch a consumer daemon.

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

Fix: tests: notification: update kernel testcase count

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ib65e4ea8ced397bdd3b30f1401121adbfeeff23a

Fix: tests: integer truncation warning on 32-bit platforms

large integer implicitly truncated to unsigned type [-Woverflow]

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

Fix: sessiond: triggers: failure to insert trigger is fatal

Inserting a trigger by name/owner should succeed if it could be added
to the top-level triggers_ht.

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

sessiond: notification-thread: switch logging to debug on GET_TRIGGER

Not finding a trigger is not necessarily an error (espeacially during
the execution of tests).

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

Tests: add trigger name/unnamed backwards compatibility test

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

lttng-ctl: separate support of named/unnamed trigger registration

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

sessiond: add support for anonymous triggers

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

Fix: lttng-ctl: assertion failure during unregistration of trigger

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

lt-trigger_name: trigger.c:302: int lttng_trigger_serialize(const struct lttng_trigger *, struct lttng_payload *): Assertion `(creds->uid).is_set' failed.

Program terminated with signal SIGABRT, Aborted.
 #0  0x00007fb74129eef5 in raise () from /usr/lib/libc.so.6
 #1  0x00007fb741288862 in abort () from /usr/lib/libc.so.6
 #2  0x00007fb741288747 in __assert_fail_base.cold () from /usr/lib/libc.so.6
 #3  0x00007fb741297646 in __assert_fail () from /usr/lib/libc.so.6
 #4  0x00007fb74169bab7 in lttng_trigger_serialize (trigger=0x5616f6f70060, payload=0x7ffe5819d140) at trigger.c:302
 #5  0x00007fb74169cef0 in lttng_trigger_copy (trigger=0x5616f6f70060) at trigger.c:859
 #6  0x00007fb74164302e in lttng_unregister_trigger (trigger=0x5616f6f70060) at lttng-ctl.c:3350
 #7  0x00005616f50c675f in register_named_trigger () at trigger_name.c:295
 #8  0x00005616f50c6879 in main (argc=1, argv=0x7ffe581a07d8) at trigger_name.c:343

Cause
=====

When creating a trigger instance and using it to unregister an existing
trigger, its credentials are unset (meaning 'default'). Expecting this,
lttng_unregister_trigger() copies the source trigger to change its
credentials to those of the caller.

Unfortunately, the trigger copy operation expects credentials to be set.

We don't run into this situation typically since the trigger instance
used to perform the unregistration is sourced from a listing or is the
same instance that was used to perform the registration (which sets the
credentials before serializing).

Solution
========

A proper implementation of "copy" is provided for the trigger object
itself. For its condition and action, we still use the same "trick"
of leveraging the serdes code to perform a deep-copy, keeping the change
small

Drawbacks
=========

None really, except that we lose some of the code sharing between
copy and serdes.

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

Rename group action files to list files

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

Rename action group to action list

This is necessary to convey that the `group` an ordered sequence of
actions. We use the term `list` to put an emphasis on the ordered nature
of the group.

Files rename follows.

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

Rename on-event to event-rule-matches

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

Move on-event*.* to event-rule-matches*.*

Code renaming follows.

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

Introduce emission site for syscall event rule

The tracer support multiple emission site configuration: entry, exit,
both.

On the CLI, the emission site is exposed directly on the event rule type
with the following syntax:

 --type=syscall:entry
 --type=syscall:exit
 --type=syscall:entry+exit

`--type=syscall` is equivalent to `--type=syscall:entry+exit`.

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

lttng list-triggers: handle all condition types

At the moment, only the event-rule-matches condition is handled by the
list-triggers commands. Change it to handle all existing condition
types.

Because these other condition types can't be created using the
command-line interface, add a util program that creates and registers
triggers for the purpose of the test. The test triggers with the
event-rule-matches condition are kept as is, created using the
command-line interface.

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

Fix: sessiond: trigger with condition not requiring event notifier cannot be listed

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

The lttng-sessiond process aborts when an lttng error query is performed
against a trigger that uses a condition other than "event-match".

Cause
=====

The trigger's condition is a LTTNG_CONDITION_TYPE_SESSION_CONSUMED_SIZE
which does not have a "domain type".

This results in the call to `abort()` in
`event_notifier_error_accounting_get_count` of the default case.

Solution
========

Check if the trigger "needs" or at least "depends" on tracer notifier.

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: I3d5f09617f95315060a611b464d1df95cb80c5bd

lttng add-trigger: remove support for conditions other than event-rule-matches

We initially only want to support the event-rule-matches condition, so
remove any trace of the other ones. They'll be added later as needed.

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

lttng {add,list,remove}-trigger: rename user id to owner uid

Implement the proposal to rename the --user-id option to --owner-uid in
the add-trigger and remove-trigger commands.  Update the output of
list-triggers as well.

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

lttng add-trigger: replace log level options with --log-level

Implement the proposal to replace the --loglevel and --loglevel-only
options with a single --log-level option.

The syntax of the argument to --log-level is:

 - `LEVEL`: to specify only this level
 - `LEVEL..`: to specify from this level up to the most critical level
 - `..`: to specify any level. Basically the same as no `--log-level`
         option.

The intent is to keep the door open to fully support ranges with the
`LEVEL1..LEVEL2` syntax.  The loglevel_parse_range_string function and
friends are implement this, but their caller in add_trigger.c,
parse_log_level_string, artificially restricts it to the two cases
shown above.

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

lttng add-trigger: replace event rule type options with --type

Implement the proposal to replace the --function, --probe,
--userspace-probe, --syscall and --tracepoint options, used to select an
event rule type, with a single --type option.

The --probe, --userspace-probe and --function options used to take an
argument, the name of the location.  For these types, the --location
option is introduced to specify that information.

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

lttng add-trigger: replace domain options with single --domain

Implement the proposal to replace the --userspace, --kernel, --log4j,
--jul and --python options, used to select a domain, with a single
--domain option that takes an argument.

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

lttng add-trigger: some updates to event rule to new syntax

Implement a few of the proposals for the event rule syntax related to
event names that we want to adopt for the add-trigger command.

 - Remove the positional argument (tracepoint name).
 - Add --name option for tracepoints, syscalls and loggers.
 - Add --event-name option for probes.
 - Rename --exclude to --exclude-names.
 - Remove the --all/-a option.  The equivalent now is to omit
   --name, which is the equivalent of --name=*.

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

lttng add-trigger: rename on-event condition to event-rule-matches

Implement the proposal to rename the on-event condition to
event-rule-matches. This patch only updates the CLI, the API will be
renamed later.

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

lttng {add,list}-triggers: use `name` instead of `id`

The right term is "trigger name", not "trigger id".  Change the option
to add-trigger accordingly, as well as the output of list-trigger.

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

lttng add-trigger: parse condition / action name as option arguments

Change the `add-trigger` command's --condition and --action options to
take the condition name and action name as option arguments.  Currently,
when we see the --condition option, we go into the parse_condition
function and expect the first argument to be the condition name (same
idea for the action).  Since the condition/action name is mandatory
after --condition/--action, it is simpler to say that --condition and
--action require an argument.

This will let the user do:

    --condition=on-event

in addition to the current syntax:

    --condition on-event

The code is a bit cleaner as a result.

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

Add .editorconfig file

Many editors support reading this file to automatically configure indent
/ whitespace settings. The author of this patch would be extremely
grateful if the maintainer of the project would consider merging the
patch in the master branch of the project's repository.

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

Allow users to create trigger with their uid

Currently, the `add-trigger` prints the following if a user uses the
`--user-id` with its own uid:
  Error: Failed to set trigger's user identity.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ie0a642b3faf2259a892def3cb19a899e61cb4705

lttng: list-triggers: implement listing of SDT userspace-probe

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id57c265dcdb3b324ffbb274ca97ead9364275cf0

Tests: cleanup: rework trigger listing tests

- Rename `list_triggers()` -> `list_triggers_matches_ok()` to make it
  obvious it's testing something,
- Add `diag` to all test cases,
- Launch only one lttng-sessiond for all test cases to reduce test
  runtime, and
- remove-trigger all triggers at the end of every test cases.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Icbbd08f521565ef1cae901bb192cf6f8f1cdb7ea

Tests: event-notifier: multi UID error accounting support

The new test case adds one root trigger and one regular user trigger as
well as apps from both of these users.

The test then confirm that the error accounting of the root trigger
reports what is happening on the regular user's app as well as its own
app.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Iaec231863de98b14891602bdae010449989de6f9

Fix: tests: quote variable in case it's not set

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ib0751699eb9deb02f47739062c99dbb8535c3163

ust: error accounting: don't print error messages if app is dead

UST applications may exit during the registering process. It's not an
error and should be expected.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I90f91252849ba362e73dad6c30b9cfdc0185abe4

sessiond: split event notifier error counter CLI options

With this commit, users can specify the size of event notifier error
counting buffers for each domain independently using the following new
lttng-sessiond options:
  --event-notifier-error-buffer-size-kernel=
  --event-notifier-error-buffer-size-userspace=

The index allocation is now also per-domain meaning that index
allocation in the kernel domain doesn't affect available indices in the
userspace domain and reversely.

Small changes:
- Add manual page description of the new options,
- Rename `struct error_account_entry` to
  `struct ust_error_accounting_entry`.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I4758d32c00cb432be377fd67eaffa11b193bad74

Clean-up: sessiond: error-query: remove unneeded goto

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

Fix: sessiond: action-executor: uninitialized session_name used in logging

CID 1452636 (#1 of 1): Uninitialized pointer read (UNINIT)
8. uninit_use_in_call: Using uninitialized value session_name when
calling fprintf

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

Clean-up: lttng: add-trigger: silence coverity warning

CID 1452634 (#1 of 1): Resource leak (RESOURCE_LEAK)
23. leaked_storage: Variable error going out of scope leaks the storage
it points to.

The code path shown by Coverity does not appear reachable, but this
fixes the warning nonetheless.

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

Fix: error-query: leak of trigger on malformed error-query comm buffer

CID 1452633 (#1 of 1): Resource leak (RESOURCE_LEAK)
10. leaked_storage: Variable trigger going out of scope leaks the
storage it points to

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

Fix: error-query: leak of trigger on allocation error

1452630 Resource leak

The system resource will not be reclaimed and reused, reducing the
future availability of the resource.

In lttng_error_query_action_create: Leak of memory or pointers to system
resources (CWE-404)

CID 1452630 (#1 of 1): Resource leak (RESOURCE_LEAK)
21. leaked_storage: Variable trigger_copy going out of scope leaks the
storage it points to.

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

Clean-up: tests: notification-client: unused assignment

1452629 Unused value

An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup or
refactoring.

In main: A value assigned to a variable is never used. (CWE-563)

CID 1452629 (#1 of 1): Unused value (UNUSED_VALUE)assigned_value:
Assigning value -1 to ret here, but that stored value is overwritten
before it can be used

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

Fix: relayd: leak of config_path on duplicate --config option

1452207 Resource leak

The system resource will not be reclaimed and reused, reducing the
future availability of the resource.

In lttng_notification_create_from_payload: Leak of memory or pointers to
system resources (CWE-404)

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

Fix: lttng-ctl: trigger leak on failure to deserialize evaluation

1452207 Resource leak

The system resource will not be reclaimed and reused, reducing the
future availability of the resource.

In lttng_notification_create_from_payload: Leak of memory or pointers to
system resources (CWE-404)

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

Fix: tests: discarded notifications: missing `list-triggers` call

I get the following test failure when running the
test_notification_notifier_discarded_count test case.

  # Kernel event notifer error counter
  ok 1 - Add trigger my_trigger
  ok 2 - No discarded tracer notification message
  ok 3 - Trigger 'errors: none' notification message
  ok 4 - Tracer notification discarded line printed
  ok 5 - Discarded tracer notification number non-zero as expected
  ok 6 - Remove trigger my_trigger
  ok 7 - No `on-event` kernel notifier enabled as expected
  ok 8 - Add trigger my_trigger
  ok 9 - No discarded tracer notification message
  not ok 10 - Trigger 'errors: none' notification message
   #   Failed test 'Trigger 'errors: none' notification message'
   #   in tests/regression/tools/notification/test_notification_notifier_discarded_count:test_kernel_notifier_discarded_count() at line 108.
  ok 11 - Remove trigger my_trigger

This happens because we test the `list-triggers` output on outdated
content. We need to call `list-triggers` right before testing the output
of it.

In this commit, I also changed the number of iteration to 2000 as it's
sufficient to generate discarded notifications.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I66d54f9178f9f37ff2fd899278e77fe50e455c10

Tests: fix: notifier discarded count: typo results in failure

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

Cleanup: tests: test_userspace_probe: remove extra whitespaces

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I6e890a6c1927feb4a09f46b200294cb2faf8a580

Cleanup: add `lttng_ht_type_str()`

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I1f7d9ae029f11a454cbda6b05eb22457d6b0be74

Fix: lttng-ctl: appending to dynamic buffer invalidates its data member

Issue
=====
The following commands fail:
  lttng add-trigger --id T0 --condition on-event -u some-event --action snapshot-session ze-session3 --path /some/path
  lttng remove-trigger T0

  Error: Attempt to create buffer view from another view with invalid length (length > space left after offset in source): source size = 0, offset in source = 0, length = 25
  Error: Invalid trigger received as part of command payload

Valgrind complains in the following way:

==706109==
==706109== Invalid write of size 4
==706109==    at 0x489FED7: lttng_unregister_trigger (lttng-ctl.c:3281)
==706109==    by 0x43C175: cmd_remove_trigger (remove_trigger.c:171)
==706109==    by 0x43F56B: handle_command (lttng.c:237)
==706109==    by 0x43E9B1: parse_args (lttng.c:421)
==706109==    by 0x43E158: main (lttng.c:470)
==706109==  Address 0x73d8d20 is 4,688 bytes inside a block of size 16,384 free'd
==706109==    at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==706109==    by 0x48C1478: lttng_dynamic_buffer_set_capacity (dynamic-buffer.c:166)
==706109==    by 0x48C138C: lttng_dynamic_buffer_append (dynamic-buffer.c:55)
==706109==    by 0x48E3325: lttng_snapshot_output_serialize (snapshot.c:120)
==706109==    by 0x48B46C3: lttng_action_snapshot_session_serialize (snapshot-session.c:173)
==706109==    by 0x48B1FB2: lttng_action_serialize (action.c:130)
==706109==    by 0x48B2DFE: lttng_action_group_serialize (group.c:165)
==706109==    by 0x48B1FB2: lttng_action_serialize (action.c:130)
==706109==    by 0x48ECE66: lttng_trigger_serialize (trigger.c:372)
==706109==    by 0x489FEA0: lttng_unregister_trigger (lttng-ctl.c:3275)
==706109==    by 0x43C175: cmd_remove_trigger (remove_trigger.c:171)
==706109==    by 0x43F56B: handle_command (lttng.c:237)
==706109==  Block was alloc'd at
==706109==    at 0x483B723: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==706109==    by 0x483E017: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==706109==    by 0x48C1478: lttng_dynamic_buffer_set_capacity (dynamic-buffer.c:166)
==706109==    by 0x48C138C: lttng_dynamic_buffer_append (dynamic-buffer.c:55)
==706109==    by 0x489FE66: lttng_unregister_trigger (lttng-ctl.c:3263)
==706109==    by 0x43C175: cmd_remove_trigger (remove_trigger.c:171)
==706109==    by 0x43F56B: handle_command (lttng.c:237)
==706109==    by 0x43E9B1: parse_args (lttng.c:421)
==706109==    by 0x43E158: main (lttng.c:470)

`lttng_unregister_trigger` samples the address of the lsm header in the
message payload. However, it does so before calling
`lttng_trigger_serialize()` which may increase the underlying buffer's
size (and cause a realloc()).

Most of the time the message buffer is large enough _or_ its realloc
yields the same address which hid the problem. However, I stumbled on a
case (a trigger which snapshots to a location) where the realloc ends-up
returning a completely different address, causing invalid data to be
sent to the session daemon.

Solution
========
Sample the lsm header address after the serialization of the trigger.

Note
====
An identical fix was done for the `lttng_register_trigger` function in:
  commit b22f4f54e95ae13edda1d4d5efd1e4845a6319c4
  Author: Jérémie Galarneau <jeremie.galarneau@efficios.com>
  Date:   Thu Feb 18 18:13:19 2021 -0500

      Fix: lttng-ctl: appending to dynamic buffer invalidates its data member

I reuse the bug explanation for this commit message.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ic50c96dcada9e0595b0fab1d2f357c183b53e1de

Fix: ust-app: error counter index never set

Issue
=====
The `struct ust_app_event_notifier_rule::error_counter_index` field is
currently never set so all error counting is done in bucket index 0.

Fix
===
Set the error counter index.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I951095dee5586111699b0ea0e3bc26c0fb4a535d

Fix: lttng: -Wshadow error in cmd_snapshot

The optarg variable name shadows a variable in an external dependency.
clang returns the following error on my machine:
  commands/snapshot.c:627:16: error: declaration shadows a variable in the global scope [-Werror,-Wshadow]
                          const char *optarg = poptGetOptArg(pc);
                                      ^
  /usr/include/x86_64-linux-gnu/bits/getopt_core.h:36:14: note: previous declaration is here
  extern char *optarg;

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I85dd7b0761ebc2c023d84ba869c0551f91f38a17

Fix: python: -Wshadow warning

Fixes warning when building Python Bindings with SWIG 3.0.12.

  lttng_wrap.c: In function ‘SWIG_Python_NewShadowInstance’:
  lttng_wrap.c:2483:65: warning: declaration of ‘swig_this’ shadows a global declaration [-Wshadow]
   SWIG_Python_NewShadowInstance(SwigPyClientData *data, PyObject *swig_this)
                                                                   ^~~~~~~~~
  lttng_wrap.c:2224:18: note: shadowed declaration is here
   static PyObject *swig_this = NULL;
                    ^~~~~~~~~
  lttng_wrap.c: In function ‘SWIG_Python_SetSwigThis’:
  lttng_wrap.c:2558:51: warning: declaration of ‘swig_this’ shadows a global declaration [-Wshadow]
   SWIG_Python_SetSwigThis(PyObject *inst, PyObject *swig_this)
                                                     ^~~~~~~~~
  lttng_wrap.c:2224:18: note: shadowed declaration is here
   static PyObject *swig_this = NULL;

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Icde5f124e914a158eb190f95e3c012b7f800d7d1

Fix: kernel consumerd: use of uninitialized variable

‘ret_add_channel’ may be used uninitialized in this function [-Wmaybe-uninitialized]

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

Clean-up: sessiond: cmd: abort() on invalid query target

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

Clean-up: sessiond: cmd: fix bogus -Wmaybe-uninitialized

Old gcc versions report:
cmd.c:4751: ‘query_target_action’ may be used uninitialized in this function [-Wmaybe-uninitialized]

For this to be reachable, a query target would have to change suddenly
during the execution of the function.

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

Remove error count property of lttng_condition_on_event

Errors related to dropped tracer messages are not reported through
the error query interface.

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

lttng: list-triggers: retrieve trigger errors using error queries

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

sessiond: implement EXECUTE_ERROR_QUERY command

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

lttng-ctl: Add error query interface

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

add-trigger: rename --fire-* to --rate-policy=*:value

With the move to firing policy to the action and the renaming to rate
policy, a rename of the CLI options is necessary.

We introduce the following format:

  --rate-policy=<type>:<value>

Where type is either: once-after or every.
Value is an unsigned long long value.

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

Rename firing policy to rate policy

This is necessary since that now that the policy is moved to the actions
it is a bit weird to use the term "firing".

CLI change is done in a later patch.

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

action executor: use an execution context to validate enqueued action before execution

Problem
======

Let's walk over the following scenario:

Trigger my_trigger:
  condition: ust event a
  action: start session S

At time T, session S exists.

At T + 1, the event A is hit.

At T + 2, the tracer event notification is received and the work item is
queued. Here session S have an id of 1.

At T + 3, the session S is destroyed and a new session S is created,
with a resulting id of 200.

At T +4, the work item is popped from the queue and begin execution and
will start session S with an id of 200 instead of the session S id 1
that was present at the queuing phase.

We effectively want to assign an execution context to an action at the
queuing phase and validate that the execution context is still valid
upon actual execution.

Solution
=====

Instead of iterating over the trigger's actions, we prepare an array of
work sub-item (action_work_subitem) that effectively is a flattened and
augmented array of the trigger's action. For now only the session id is
an action level execution context.

Each action handler is responsible of validating the execution context
before performing the action.

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

trigger/action executor: move trigger registration state change to client thread

Set the unregistered state of the sessiond side trigger object in the
client thread since we want to minimize the possibility of the
notification thread being stalled due to a long execution of an action
in the action executor thread.

Stalling the client thread is, comparatively, less harmful.

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

notification-thread: add `GET_TRIGGER` command

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ifc94ea894999b9da796aa4fda0d929d237e12d3e

action executor: execute action only if the associated trigger is registered

It was decided that a trigger removal should have immediate effect and
not result in a waiting on action queued to be executed.

There was two major way to do this:

1) On unregistrer trigger, lock the action executor queue and remove
all work-item related to the trigger ebing unregistered.

2) Mark the trigger as "unregistered" and validate its state when a work
item is ready for execution. If the trigger is marked as "unregistered",
simply consume and skip the work item.

To isolate the un-registration and the execution of a work item
depending on that trigger, we use the trigger lock to have exclusivity
during the execution for that trigger.

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

trigger: keep state of if a trigger is currently registered

Since a trigger can be referenced even when is was "unregistered" in
other part of lttng-sessiond, namely the action executor queue, we must
keep track of the registration state.

This will allows us to easily skip any actions to be executed
if the associated trigger is "unregistered" at the moment of
execution. This is implemented in a following patch.

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

Tests: fix: leak of notification-client arguments

Valgrind reports the following leaks:

==334435== HEAP SUMMARY:
==334435==     in use at exit: 8,568 bytes in 24 blocks
==334435==   total heap usage: 846 allocs, 822 frees, 1,425,964 bytes allocated
==334435==
==334435== 9 bytes in 1 blocks are definitely lost in loss record 1 of 11
==334435==    at 0x483E77F: malloc (vg_replace_malloc.c:307)
==334435==    by 0x4BCC5BE: strdup (in /usr/lib/libc-2.33.so)
==334435==    by 0x10A48B: main (notification-client.c:123)
==334435==
==334435== 13 bytes in 1 blocks are definitely lost in loss record 2 of 11
==334435==    at 0x483E77F: malloc (vg_replace_malloc.c:307)
==334435==    by 0x4BCC5BE: strdup (in /usr/lib/libc-2.33.so)
==334435==    by 0x10A473: main (notification-client.c:120)
==334435==
==334435== 27 bytes in 1 blocks are definitely lost in loss record 3 of 11
==334435==    at 0x483E77F: malloc (vg_replace_malloc.c:307)
==334435==    by 0x4BCC5BE: strdup (in /usr/lib/libc-2.33.so)
==334435==    by 0x10A444: main (notification-client.c:114)

Free the strdup()'ed' arguments.

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

tests: trigger action firing policy

Implements the regression tests for the trigger action firing polices.

For now the focus is put on the notify action behavior. In the future,
the ability to fetch the number of time an action was enqueued for
execution and the number of type it was executed should greatly
facilitate this work. For now, use the notify action for minimal
regression testing.

gen-ust-events is modified to allow a caller to specify that an `end`
event should be emitted at the end of the program. This is used to
guaranteed that all previous event tracer notifications should be
received when the `end` event notification is received. Note that
ordering is guaranteed for delivery of tracer notification and
notification for a given process.

notificiation-client is modified to allow reception of N notifications
and to validate that it received the count it expects.

notificiation-client is modified to allow reception of N notifications
and to exit only when an `end` event notification is received. This
allow us validate the firing policy.

The tests are pretty straightforward. We register 2 triggers, one with
an event rule condition on `tp:tptest` and the other one with a event
rule condition on `tp:end`. From there we perform a phase of event hits
were we expect no notification except for the `tp:end` then we force a
single event hit were we expect a notification for `tp:tptest`. For the
fire every N policy, we rinse and repeat to validate the behaviour. For
the once after N, we simply do a third phase were we generate N events
and expect no notification.

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

Move firing policy from lttng_trigger to lttng_action

After some reflection on the future of the importance of the trigger
feature and the centralization we wish to carry around it, it is
required that the notion of firing policy be moved from the trigger
object to each action object of a trigger.

This is necessary since we plan on introducing tracer side actions, such
as increment value of map. Controlling the firing policy on the tracer
side is not an easy thing to do since for UST tracing a lot a
synchronizations must take place and also we must define the behaviour
when multiple apps are present. Hence, we need a way to ensure that we
are not painting ourself in a corner. The middle ground that was chosen
was to move the notion of firing policy to the action object level. This
allows us to scope the concept to the action and decide for each type if
firing policy can be supported and, as needed, define the behaviour per
action type.

Essentially this patch perform the complete transition. It removes the
notion of firing policy at the trigger level and exposes the firing
policy of each action type if applicable.

CLI
======

For the `add-trigger` command the change essentially boils down to
moving the `--fire-every` and `--fire-once-after` from a top-level
parsing to the parsing of each actions. Yes, for now all actions
supports the `--fire-*` options but it will not be the case in the
future. A side effect of this is that a user could decide to have
different firing policy for each actions, but this also mean that if a
user want to apply the same firing policy across actions, the user needs
to specify it for each actions. This could be solved in the future as
the trigger feature matures and that common ground are found in the
behaviour or implementation of the actions (tracer side action, async
action, sync actions etc.) such that "syntactic sugar" options emerge.

As for the `list-trigger`, we move the firing policy printing to each
actions.

Tests have been updated to reflect the changes.

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

action-executor: consider action firing policy on action execution

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

test: unit: snapshot session action

Note that the introduced test are mostly toward the firing policy
parameter.

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

Implement firing policy for the snapshot session action

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

tests: units: action: stop session

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

Implement firing policy for stop session action

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

tests: unit: action: start_session

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

Implement firing policy for the start session action

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