source.text.dmesg: use BT_COMP_LOGE_APPEND_CAUSE

Use BT_COMP_LOGE_APPEND_CAUSE where possible, when returning error
statuses.  Some errors paths due to allocation failure now return MEMORY_ERROR,
rather than ERROR.

Change-Id: I32a15d64538a23406114ef661990928f6f9ed296
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3243
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

source.text.dmesg: replace switch to convert status with cast

Replace the switch currently used in create_port, to convert the status of
bt_self_component_source_add_output_port, with a simple cast, as per standard
procedure.  Since create_port becomes trivial, remove it and inline the code in dmesg_init.

Change-Id: Iccdf0ba298c73616b7c86b14e5208de4519b77d8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3395
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

configure: remove -Wno-format-nonliteral

This patch removes all the offending instances of -Wformat-nonliteral
and removes -Wno-format-nonliteral from the warning flags we enable.

In cases where we re-use the same format string multiple times, like:

    const char *const msg = "Hello %d\n";

    if (something) {
        pass(msg, value);
    } else {
        fail(msg, value);
    }

... my compiler (gcc (Arch Linux 9.2.1+20200130-2) 9.2.1 20200130)
complains that the format string is not a literal, even though the `msg`
variable is const and assigned a literal.  I've replaced these with a
macro.

In other places, we manually manipulate and craft format strings, to
I've just disabled the warning there.

The generated SWIG wrapper for the error appending functions cause some
warnings like this:

    bt2/native_bt.c: In function ‘_wrap_current_thread_error_append_cause_from_component__varargs__’:
    bt2/native_bt.c:7839:3: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
     7839 |   result = (bt_current_thread_error_append_cause_status)bt_current_thread_error_append_cause_from_component(arg1,(char const *)arg2,arg3,(char const *)arg4,ar
    g5);
          |   ^~~~~~

Since we don't actually need these functions from the Python bindings,
I've made SWIG not generate a wrapper for them.

Change-Id: Ic6834dc44abce7be8e113e9cbf3f33a3f09809e2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3233
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

sink.text.details: sprinkle BT_COMP_LOGE_APPEND_CAUSE liberally

Add some BT_COMP_LOGE_APPEND_CAUSE where we would return an error
without logging, or replace existing BT_COMP_LOGE with
BT_COMP_LOGE_APPEND_CAUSE.

Change-Id: I6eeaaa713fe9b4112df82b3c0fccb16a4f54f6c4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3222
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

sink.text.details: replace switch to convert status with cast

Replace the switch currently used in details_consume, to convert the
status of bt_message_iterator_next, with a simple cast, as per standard
procedure.

Change-Id: Iea35bd26f4af983d7cca37fc01b2b2f903cc73da
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3394
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

flt-utils.muxer: use BT_COMP_LOGE_APPEND_CAUSE

Replace all BT_COMP_LOGE with BT_COMP_LOGE_APPEND_CAUSE.

Change-Id: I7436a0d37f3d3c193c400ed55ef41310ab2ec1f0
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3260
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: flt-utils.muxer: reference leak in muxer_msg_iter_add_upstream_msg_iter error path

Let's say we fail to allocate `muxer_upstream_msg_iter->msgs`, we will have
already gotten a reference on `self_msg_iter`, which we need to put.  Calling
destroy_muxer_upstream_msg_iter ensures we do that.

Change-Id: I9b113d2e335d529599cb9197c39c8675915508e5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3393
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

lib: add `size >= 1` pre-condition to bt_field_class_integer_set_field_value_range

An integer of 0 bits is not very useful.

Change-Id: I00a4114dc4a949a4876f810f603226a1c5936751
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3385
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: src.text.dmesg: add missing assignment of `status` on error path

The error path under `if (!*msg)`, originally at line 789, is missing
assigning an error status to the `status` variable, fix it.

Change-Id: I2b47c6ce7c6099a6db68c4da108d7c0886c7177e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3384
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: sink.text.details: goto error when failing to add input port

If bt_self_component_sink_add_input_port fails, the current code does
not goto error.  This patch fixes it.  It also changes the switch, used
to convert from `add_port_status` to `status`, to a cast, as is the
practice throughout the project.

Change-Id: I82b2719316ad00ffd9d9c14b86b8890b98130669
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3383
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Move to kernel style SPDX license identifiers

The SPDX identifier is a legally binding shorthand, which can be used
instead of the full boiler plate text.

See https://spdx.org/ids-how for details.

Change-Id: I7c25a3bc48ee328500a604cb276877d4cadfa997
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3227
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: src.ctf.fs: initialize the other_entry variable

Initialize the pointer other_entry to silence this warning:

    | ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function 'ds_index_insert_ds_index_entry_sorted':
    | ../../../../../git/src/plugins/ctf/fs-src/fs.c:702:5: error: 'other_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    |  702 |    !ds_index_entries_equal(entry, other_entry)) {

This was encountered with gcc 9.2.0 at the -Og optimization level.
After inspection, it appears that this is a false positive, the
`other_entry` pointer can only be used after being initialized first.

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Change-Id: Icf63e605cf543c3eb29e5aadec18b22b137ee9da
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3353
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

bt2: make `_EventConst` a mapping

The `_EventConst` class already implemented the __getitem__() method
to make it easy to access a payload, specific context, common context,
or packet context field (in this order) by name, for example:

    print(event['next_prio'])

If two root fields contain fields which share the same name, one of them
has the priority and the other one is not accessible through this
interface.

This patch makes the `_EventConst` class a full mapping protocol,
inheriting `collections.abc.Mapping`. This patch implements the
__iter__() and __len__() methods so as to let `collections.abc.Mapping`
implement __contains__(), keys(), items(), values(), get(), __eq__(),
and __ne__(). Now you can do, for example:

    if 'next_prio' in event:
        print(event['next_prio'])

__iter__() keeps a set of yielded field names so as to avoid repeating
field names.

__len__() simply reuses __iter__().

`test_event.py` is updated to test the new features.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2485e0df2373005fada0d0732c6269acbce5457c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3343
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

Fix: bt2: _EventConst.__getitem__(): check if event has a packet

I'm also adding a test to check this. Without this patch and an invalid
key, __getitem__() throws `AttributeError` instead of the expected
`KeyError`.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ie6258a2354ece8aee6c8530587c900ea08e45fe8
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3349
Tested-by: jenkins <jenkins@lttng.org>

bt2: honor build system compiler/linker preferences

This is an attempt to fix the dreaded "compiling the Python native
module with a custom compiler or compiler-specific flag" problem.

The problem may arise when building with a CC different than what the
Python interpreter was compiled with.  It can manifests itself in two
different ways, as far as I know.  But in both cases, it's due to us
overriding the compiler and compiler flags when invoking setup.py to
build the native modules, and how distutils invokes the compiler and
linker to build the native modules.

Scenario 1
----------

Things fail when trying to compile with a compiler other than what
Python has been compiled with, and using in `CFLAGS` a compiler flag
unknown to the compiler Python has been compiled with.

For example, on Ubuntu 18.04, we get this when building with CC=clang
(the -Wtautological-constant-out-of-range-compare is a clang-specific
warning flag currently specified in configure.ac):

    x86_64-linux-gnu-gcc ... -Wtautological-constant-out-of-range-compare ... -o build/build_lib/bt2/_native_bt.cpython-38-x86_64-linux-gnu.so
    x86_64-linux-gnu-gcc: error: unrecognized command line option ‘-Wtautological-constant-out-of-range-compare’
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

This is due to the fact that:

- The default link command used by distutils to link shared objects uses
  its default compiler driver (gcc on Linux)
- It passes `CFLAGS` to the linker

Because of this, we end up passing a clang-specific warning flag to gcc,
which proceeds to error out.

To fix this, I have considered setting the LDSHARED variable to
override the command used for linking shared objects.  If the compiler
driver used to drive the linking is the same as the compiler driver used
for compiling, it should understand all the passed flags.

However, it is not obvious to do this right, especially, considering the
various platforms.  But most importantly, it is doesn't help with the
next scenario.

Scenario 2
----------

On Arch Linux (and presumably on Fedora too [1]), the flags passed by
distutils to the compiler contain `-fno-semantic-interposition`, which
is a gcc-specific flag.  When building with CC=clang, we therefore get
this when compiling:

    building 'bt2._native_bt' extension
    clang ... -fno-semantic-interposition ... -c bt2/native_bt.c -o build/temp.linux-x86_64-3.8/bt2/native_bt.o
    clang-9: error: unknown argument: '-fno-semantic-interposition'

clang errors out, because it gets passed a gcc-specific flag.

[1] https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup

The fix
-------

Two important distutils configuration variables are at play in this
problem:
  - LDSHARED: defines a command to link a build target
  - CFLAGS: contains the compiler flags used to build the python
    interpreter.

The configuration variables are changed on access by overriding
distutils' get_config_vars().

In the case of `LDSHARED`, distutils allows it to be specified as an
environment variable which would probably be cleaner (if it actually
works, I haven't tested). distutils seems to honor the environment
`CC` _sometimes_ (depending on whether or not it has performed the
`customize_compiler` step?)

The override always uses the environment `CC` and completely foregoes
the `LDSHARED` configuration variable if `LDFLAGS` are provided. If no
`LDFLAGS` are specified, the compiler is replaced in the LDSHARED
command.

Unfortunately, the CFLAGS environment variable is only appended to
the Python interpreter's build-time CFLAGS, which doesn't solve our
problem. get_cflags() completely overrides the CFLAGS configuration
variable to use babeltrace's build system-specified CFLAGS.

Drawbacks
---------

I can't think of a scenario where this doesn't work, but I'm afraid
this will break in non-trivial build environments.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: If3142ddb228758e63a986e735cb8f9d89dd39b67
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3286
Tested-by: jenkins <jenkins@lttng.org>

configure: enable -Wsuggest-attribute=format

The -Wsuggest-attribute=format warning makes the compiler suggest places
where __attribute__((format(...))) would likely be useful.  This patch
turns it on and adds such attributes everywhere my compiler (GCC 9)
suggested to add them.

In cases where we re-use the same format string multiple times, like:

    const char *const msg = "Hello %d\n";

    BT_LOGE(msg, some_value);
    BT_CURRENT_THREAD_ERROR_APPEND_CAUSE_FROM_MESSAGE_ITERATOR("modname", msg, some_value);

... my compiler (gcc (Arch Linux 9.2.1+20200130-2) 9.2.1 20200130)
complains that the format string is not a literal, even though the `msg`
variable is const and assigned a literal.  I've replaced these with a
macro.

Change-Id: I40dd2e70649ec2b651e0109097c217ca9557ad69
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3232
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

configure: simplify warning flags detection

We currently use the AX_COMPILER_FLAGS macro to detect the warning flags
that the current compiler supports.  It works, but is quite invasive.
It unconditionally enables a bunch of warnings we don't want, which
forces us to disable them with many -Wno-foo switches.

Instead of using AX_COMPILER_FLAGS, we can use the slightly lower lever
macro AX_APPEND_COMPILE_FLAGS to achieve our goal of detecting which
warning flags are supported.  This is what we ended up using in
lttng-tools (a completely unrelated project, but that has a suspiciously
high ratio of contributors in common with Babeltrace).

I looked in our git history to see which warning flags were mentioned in
commit messages.  I have added the flags that did find actual problems
and are not enabled by default to the AX_APPEND_COMPILE_FLAGS invocation.
I have also added the flags that AX_COMPILER_FLAGS did provide, which we
didn't need to disable.

The --{enable,disable}-Werror flag is added using an explicit
AC_ARG_ENABLE.  In lttng-tools, it was decided to _not_ have -Werror by
default, so I suggest we do the same in Babeltrace, for consistency
(although it saddens me very much).  Developers who want to build with
-Werror will need to pass --enable-Werror.

Note that with this patch, we lose the following configure switch, that
is provided by AX_COMPILER_FLAGS:

  --enable-compile-warnings=[no/yes/error]

Change-Id: If968f7385a7f5c48d27f402c76bc26241a8f505a
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3209
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>

sink.text.details: remove LOG_WRONG_PARAM_TYPE

It is unused since we have added the more sophisticated parameter
validation utility.

Change-Id: I7ed57026903fd891f2118b6c6bd03841e07f5954
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3221
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

doc: bt_field_class...get_mapping_labels...(): clarify RV's validity

The label array which
bt_field_class_enumeration_unsigned_get_mapping_labels_for_value() and
bt_field_class_enumeration_signed_get_mapping_labels_for_value() return
remains valid as long as:

* The enumeration field class is not modified.

* You don't call the same function again with the same enumeration
  field class.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I7b197ab5e176c77f4418d23b12e194c6477e5cf8
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3224

doc/api/libbabeltrace2/style.css: make font weight of `.intertd` normal

For some reason, `.intertd` paragraphs, which Doxygen creates when a
given table cell (used for parameter descriptions, amongst other things)
contains more than one paragraphs, are bold.

Here's an example to generate such paragraphs:

    @param some_param
        @parblock
        Normal paragraph.

        Bold paragraph.

        Also bold.
        @endparblock

I don't know the bold font weight's rationale here, but it does not look
pretty, so force the weight to be normal in `style.css`.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ida6970a75f6cc1b4ac4f1fc873e86a3b453d09ac
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3223

flt.utils.muxer: initialize variable to silence -Wmaybe-uninitialized warning

gcc 4.8 shows this warning:

      CC       muxer.lo
    In file included from /home/smarchi/src/babeltrace/src/plugins/utils/muxer/muxer.c:26:0:
    /home/smarchi/src/babeltrace/src/plugins/utils/muxer/muxer.c: In function ‘muxer_msg_iter_next’:
    /home/smarchi/src/babeltrace/src/logging/comp-logging.h:145:3: error: ‘next_return_ts’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
       (void) BT_CURRENT_THREAD_ERROR_APPEND_CAUSE_FROM_COMPONENT(  \
       ^
    /home/smarchi/src/babeltrace/src/plugins/utils/muxer/muxer.c:1042:10: note: ‘next_return_ts’ was declared here
      int64_t next_return_ts;
              ^

I looked at the interaction between muxer_msg_iter_do_next_one and
muxer_msg_iter_youngest_upstream_msg_iter (which is the one that sets
next_return_ts), and I think the code is fine:

 * muxer_msg_iter_youngest_upstream_msg_iter returns either OK, END, or
   an error status code (< 0).  It does not return AGAIN, because it
   does not call the upstream iterators, it works with the data already
   available to the muxer component.
 * muxer_msg_iter_do_next_one, only uses next_return_ts when
   muxer_msg_iter_youngest_upstream_msg_iter returns OK.
 * When muxer_msg_iter_youngest_upstream_msg_iter returns OK, it always sets
   *ts_ns.

I think that initializing the variable to suppress this warning doesn't
hurt, and I don't see any other modifications needed to the code.

Change-Id: If4e8f1fd381a6ec2da044cf4cb8ffc8de2b373d9
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3210
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

common: cast arguments to character classification functions to unsigned char

We get failures of this type on the cygwin CI machine:

    15:28:20 common.c: In function `bt_common_string_is_printable`:
    15:28:20 common.c:786:16: error: array subscript has type `char` [-Werror=char-subscripts]
    15:28:20   786 |   if (!isprint(*ch) && *ch != '\n' && *ch != '\r' &&
    15:28:20       |                ^~~

This error only pops up on some platforms that have isprint implemented
using a lookup table.  This table is indexed using `*ch`, which is a
char.  And because char is signed on some platforms, gcc warns that this
is dangerous: we could access the array with a negative index, which
would yield unexpected results.

This is on purpose in newlib (the libc used by cygwin, apparently), see
this comment:

  https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/ctype.h;h=a0009af17485acc3d70586a0051269a7a9c350d5;hb=HEAD#l78

The Linux man page for isprint also mentions it:

       The standards require that the argument c for these functions is
       either EOF or a value that is representable in the type unsigned
       char.  If the argument c is of type char, it must be cast to unsigned
       char, as in the following example:

           char c;
           ...
           res = toupper((unsigned char) c);

       This is necessary because char may be the equivalent of signed char,
       in which case a byte where the top bit is set would be sign extended
       when converting to int, yielding a value that is outside the range of
       unsigned char.

Add casts to unsigned char to fix the various instances of this error.

Change-Id: Ice2305490997f595c6f5140a8be2abaa7fd1d8f6
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3194
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: Michael Jeanson <mjeanson@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

sink.text.pretty: remove error checks for bt_field_borrow_class_const results

bt_field_borrow_class_const can't fail, so these error checks are
unnecessary.  Removing them reveals that some of these variables were in
fact unused, so remove them.

Change-Id: I57867e0eb01db3bd7c73dfedc9d1772cbfad02d5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3155
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

py-common: clean-up: unreachable error handling code

Both `bt_py_common_format_exception()` and `bt_py_common_format_tb()`
use the same error handling pattern of defining an `error` label and
free-ing `msg_buf` if it has been created before jumping there.

In both cases, the creation of `msg_buf` is the last operation that
can fail, which makes the check, and clean-up, unrechable.

From Coverity's report:
1408326 Logically dead code

The indicated dead code may have performed some action; that action
will never occur.

In bt_py_common_format_tb: Code can never be reached because of a
logical contradiction (CWE-561)

Reported-by: Coverity Scan
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I81b5a2db2cefe1fe08e25819bfa2d8e0fd78ee82
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3154
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

Fix: configure.ac: silently accepting invalid Python configuration

Currently, if the user builds and installs the project with:
  ./configure --enable-python-plugins
  make
  make install

They won't be able to do the `import bt2` necessary to start defining
their BT2 plugin. To write a Python plugin , the user needs to use the
Python bindings as well.

The user gets this:
  >>> import bt2
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ModuleNotFoundError: No module named 'bt2'

As suggested by Simon Marchi, I implemented the following truth table
for the Python-related configure options (--enable-python-bindings and
 --enable-python-plugins):

  plugins | bindings
  --------+---------
  missing | missing  -> both disabled
  missing | enable   -> plugins disabled, bindings enabled
  missing | disable  -> both disabled
  enable  | missing  -> both enabled
  enable  | enable   -> both enabled
  enable  | disable  -> error
  disable | missing  -> both disabled
  disable | enable   -> plugins disabled, bindings enabled
  disable | disable  -> both disabled

This makes sure the user doesn't get into an invalid configuration _and_
offers the sane default of enabling the bindings (if they were omitted)
when plugins are enabled explicitly.

Fixes #1240

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I3b94d8911568290239add616f8e794ad73e278db
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3152
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>

Cleanup: configure.ac: remove redundant `AC_ARG_ENABLE` parameters

According to the documentation [1], the last parameter of the
`AC_ARG_ENABLE()` macro (`action-if-not-given`) is executed only if
neither `--enable-foo` nor `--disable-foo` is provided.

So in cases where the feature is disabled by default, there is no need
to turn if off explicitly in the `action-if-not-given` parameter as
the macro will simply not set the `enable_foo` to `yes`.

Also, I fixed up the comment for the `enable_man_pages` variable.

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Package-Options.html

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I7416bed88ed1e719ef896f0ca0117b382d99f68f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3151
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>

configure: Add flags as hints when option is disabled

This helps user discover the options after running ./configure, to see
how to enable more options, without having to read the documentation

Change-Id: I5684c14c7eec8f7dc37f3eb8493ea821e18a8365
Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3148
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

Fix: plugin-dev.h: Disable address sanitizer on pointer array section variables

The plugin header declares pointer global variables in plugins meant to
be placed contiguously within their own sections, and then used as an
array of pointers when loading the plugin.

Clang Address Sanitizer adds redzones around each variable, thus leading
to detection of a global buffer overflow.

Those redzones should not be placed within this section, because it
defeats its purpose. Therefore, teach asan not to add redzones
around those variables with an attribute.

Note that there does not appear to be any issue with gcc (tested with
gcc-8 with address sanitization enabled), and gcc ignores the
no_sanitize_address attribute when applied to a global variable.

Fixes: #1231
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I5488d61a7d714e6525a3a623d303c5fd30b76bc2
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3102
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

tests: fix shellcheck warnings in cli/convert/test_auto_source_discovery_{log_level,params}

shellcheck complains:

    In test_auto_source_discovery_params line 42:
    print_test_params="--params what=\"test-params\""
                       ^---------------------------^ SC2089: Quotes/backslashes will be treated literally. Use an array.

    In test_auto_source_discovery_params line 68:
     "${dir_ab}" --params 'test-allo="madame"' ${print_test_params} \
                                                      ^------------------^ SC2090: Quotes/backslashes in this variable will not be respected.
                                                      ^------------------^ SC2086: Double quote to prevent globbing and word splitting.

    Did you mean:
     "${dir_ab}" --params 'test-allo="madame"' "${print_test_params}" \

It would be cleaner to make it print_test_params an array, like we do
for details_sink.

Consistently double-quotes references to print_test_params and
details_sink to avoid the "word splitting" warnings.

Change-Id: I6b18effc29f3c453949b4c181e528e2a60cea4e4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3145
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warnings in cli/convert/test_convert_args

Fix:

    In test_convert_args line 98:
    test_bt_convert_run_args 'path non-option arg + user source named `auto-disc-source-ctf-fs`' "--component auto-disc-source-ctf-fs:source.salut.com $path_to_trace" "--component auto-disc-source-ctf-fs:source.salut.com --component auto-disc-source-ctf-fs-0:source.ctf.fs --params 'inputs=[\"$path_to_trace\"]' --component pretty:sink.text.pretty --component muxer:filter.utils.muxer --connect auto-disc-source-ctf-fs:muxer --connect auto-disc-source-ctf-fs-0:muxer --connect muxer:pretty"
                             ^-- SC2016: Expressions don't expand in single quotes, use double quotes for that.

    In test_convert_args line 99:
    test_bt_convert_run_args 'path non-option arg + user sink named `pretty`' "--component pretty:sink.my.sink $path_to_trace" "--component pretty:sink.my.sink --component auto-disc-source-ctf-fs:source.ctf.fs --params 'inputs=[\"$path_to_trace\"]' --component muxer:filter.utils.muxer --connect auto-disc-source-ctf-fs:muxer --connect muxer:pretty"
                             ^-- SC2016: Expressions don't expand in single quotes, use double quotes for that.

    In test_convert_args line 100:
    test_bt_convert_run_args 'path non-option arg + user filter named `muxer`' "--component muxer:filter.salut.com $path_to_trace" "--component muxer:filter.salut.com --component auto-disc-source-ctf-fs:source.ctf.fs --params 'inputs=[\"$path_to_trace\"]' --component pretty:sink.text.pretty --component muxer-0:filter.utils.muxer --connect auto-disc-source-ctf-fs:muxer-0 --connect muxer-0:muxer --connect muxer:pretty"
                             ^-- SC2016: Expressions don't expand in single quotes, use double quotes for that.

    In test_convert_args line 101:
    test_bt_convert_run_args 'path non-option arg + --begin + user filter named `trimmer`' "$path_to_trace --component trimmer:filter.salut.com --begin=abc" "--component trimmer:filter.salut.com --component auto-disc-source-ctf-fs:source.ctf.fs --params 'inputs=[\"$path_to_trace\"]' --component pretty:sink.text.pretty --component muxer:filter.utils.muxer --component trimmer-0:filter.utils.trimmer --params 'begin=\"abc\"' --connect auto-disc-source-ctf-fs:muxer --connect muxer:trimmer-0 --connect trimmer-0:trimmer --connect trimmer:pretty"
                             ^-- SC2016: Expressions don't expand in single quotes, use double quotes for that.

Because we have backticks in single quotes, like:

  'hello `you`'

shellcheck thinks that we want to execute the command "you".  So it
warns us that this is not going to happen, given that it is between
single quotes.  This is fine though, as we actually want a string with
backticks in it.

Circumvent it by using double quotes, but escaping the backticks.

Change-Id: Iead2f7842463167969d52f9324b3954896b87686
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3144
Tested-by: jenkins <jenkins@lttng.org>

tests: add expected error strings cli/convert/test_convert_args

It looks like this test was meant to optionally check the error strings,
the in the "failure" test cases, but it's not used at the moment.  This
patch adds an error string to check for each use of
test_bt_convert_fails.

Change-Id: I253743fdd174be5ba09c0b07f4fd1bc4dbf767da
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3147
Tested-by: jenkins <jenkins@lttng.org>

tests: cleanup cli/convert/test_convert_args

A few cleanups:

- Use bt_cli instead of running the babeltrace binary by hand.
- Give a base name to the temporary files.
- Split CLI arguments into an array before passing them to bt_cli (this
  avoids a shellcheck warning).

bt_cli prints the executed command line, so it becomes unnecessary to
print it manually in this test, which allows simplifying things a bit.

Change-Id: I043099b460ba4ab428beb305de4fe0ad51c20de7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3142
Tested-by: jenkins <jenkins@lttng.org>

Fix: cli: use BT_CLI_LOGE_APPEND_CAUSE instead of printf to print errors

While fixing up the test cli/convert/test_convert_args, I noticed that
some error messages were printed on stdout, and not using error causes.
Indeed, they are printed directly using printf.

Change them to use BT_CLI_LOGE_APPEND_CAUSE.

This is tested by a following patch which updates
cli/convert/test_convert_args.

Change-Id: I18a901d50b643293dd806c1fbe7d2372dc8bd46f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3146
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warnings in plugins/sink.ctf.fs/succeed/test_succeed

Fix:

    In test_succeed line 44:
    local temp_out_trace_dir="$(mktemp -d)"
  ^----------------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 73:
    local temp_gen_trace_dir="$(mktemp -d)"
  ^----------------^ SC2155: Declare and assign separately to avoid masking return values.

Change-Id: I1d7d419d8a11458200d6bf97b1558c8183315dce
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3141
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warning in plugins/src.ctf.lttng-live/test_live

shellcheck says:

    In test_live line 143:
            if ! "$BT_TESTS_BT2_BIN" $cli_args 1>"$cli_stdout_file" 2>"$cli_stderr_file"; then
                                     ^-------^ SC2086: Double quote to prevent globbing and word splitting.

    Did you mean:
            if ! "$BT_TESTS_BT2_BIN" "$cli_args" 1>"$cli_stdout_file" 2>"$cli_stderr_file"; then

In this case, we do want to pass the $cli_args string as multiple
arguments, so we don't want to just double-quote it.  Circumvent the
warning by splitting it explicitly into an array, then passing the array
using array expansion.  I think this is clearer anyway, as it shows the
intent of splitting the arguments more explicitly than relying in the
implicit splitting done by the shell.

Also, change it to use bt_cli, instead of running the babeltrace binary
by hand.

Change-Id: Idd277fc792e9a426213932566c3c096a53b56d9e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3140
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warnings in plugins/src.ctf.fs/test_deterministic_ordering

Fix the path to utils.sh, so that shellcheck finds it.

Change-Id: Ifa592f6e62ccc6df991ffe2ec7afd9c9ea53f136
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3139
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warnings in plugins/src.ctf.fs/query/test_query_metadata_info

Fix:

    In test_query_metadata_info line 32:
    this_dir_build="$BT_TESTS_BUILDDIR/$this_dir_relative"
    ^------------^ SC2034: this_dir_build appears unused. Verify use (or export if used externally).

    In test_query_metadata_info line 41:
    local temp_stdout_output_file="$(mktemp -t actual_stdout.XXXXXX)"
  ^---------------------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_query_metadata_info line 42:
    local temp_stderr_output_file="$(mktemp -t actual_stderr.XXXXXX)"
  ^---------------------^ SC2155: Declare and assign separately to avoid masking return values.

Change-Id: I747d8092bf4625a748afb313b094e6782824c407
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3138
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warnings in plugins/src.ctf.fs/succeed/test_succeed

Fix the path to utils.sh, so that shellcheck finds it.  Then, fix:

    In test_succeed line 69:
            local temp_stdout_output_file="$(mktemp -t actual_stdout.XXXXXX)"
                  ^---------------------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 70:
            local temp_greped_stdout_output_file="$(mktemp -t greped_stdout.XXXXXX)"
                  ^----------------------------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 71:
            local temp_stderr_output_file="$(mktemp -t actual_stderr.XXXXXX)"
                  ^---------------------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 103:
            local temp_stdout_output_file="$(mktemp -t actual_stdout.XXXXXX)"
                  ^---------------------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 104:
            local temp_stderr_output_file="$(mktemp -t actual_stderr.XXXXXX)"
                  ^---------------------^ SC2155: Declare and assign separately to avoid masking return values.

Change-Id: Ia67e0726aa898df7a761a3284fdd2919ac2570e8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3137
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warnings in plugins/flt.lttng-utils.debug-info/test_succeed

Fix the path to utils.sh, so that shellcheck finds it.  Then, fix:

    In test_succeed line 38:
    this_dir_build="$BT_TESTS_BUILDDIR/$this_dir_relative"
    ^------------^ SC2034: this_dir_build appears unused. Verify use (or export if used externally).

    In test_succeed line 70:
            local actual_stdout=$(mktemp -t test_debug_info_stdout_actual.XXXXXX)
                  ^-----------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 71:
            local actual_stderr=$(mktemp -t test_debug_info_stderr_actual.XXXXXX)
                  ^-----------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 72:
            local expected_stdout=$(mktemp -t test_debug_info_stdout_expected.XXXXXX)
                  ^-------------^ SC2155: Declare and assign separately to avoid masking return values.

    In test_succeed line 73:
            local expected_stderr=$(mktemp -t test_debug_info_stderr_expected.XXXXXX)
                  ^-------------^ SC2155: Declare and assign separately to avoid masking return values.

Change-Id: Id9f0d3be21ef215a416946b702f915d98fb539d2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3136
Tested-by: jenkins <jenkins@lttng.org>

tests: fix shellcheck warnings in plugins/flt.utils.muxer/succeed/test_succeed

Fix the path to utils.sh, so that shellcheck finds it.  Then, fix:

    In test_succeed line 70:
            run_test $i
                     ^-- SC2086: Double quote to prevent globbing and word splitting.

    Did you mean:
            run_test "$i"

Change-Id: I76e1fdf5569c5acc487d0b55abcf1d9babd242cd
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: shellcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3135
Tested-by: jenkins <jenkins@lttng.org>

tests: improve flt.utils.trimmer/test_trimming to test streams without packets

Augment the test to make it test streams without packet support.  A new
parameter 'with-packet-msgs' must be passed to the test source component to
control whether it will emit packet messages.

There are now two configuration axis in this test (with and without
stream message clock snapshots, with and without packet messages), which
gives 4 configurations.  I think it's still manageable to have them all
written explicitly.  However, if we are to add a third configuration
axis, I think we'll need to refactor the test to avoid having all the
expected outputs written explicitly, as it will become too big to be
manageable.

Change-Id: I0b488aa3f1506e9d43f320c1643a65db5317d63c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3106
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: flt-utils.trimmer: accept streams without packet support

When the trimmer notices a new stream, it checks various properties to
make sure it is able to handle it.  If the stream's packet messages
don't have default clock snapshots, it returns an error, because that it
not supported right now.

However, this also has the unwanted effect of rejecting streams which
don't support packets.  Indeed, the
bt_stream_class_packets_have_beginning_default_clock_snapshot and
bt_stream_class_packets_have_end_default_clock_snapshot functions return
false in this case.

Streams without packet support are supported by the trimmer, there is
not reason to reject them.  Fix that by checking if the stream supports
packets before checking if the packet messages have default clock
snapshots.

This is covered by a test that is added by an following patch in this
series.

Change-Id: If4732e89680d8dc8f02cb9be56d3a0d39fed6afe
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3105
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: lib: don't assume that streams have packets in auto seek

We get a segmentation fault when trying to instantiate a trimmer
downstream of a component that creates streams without packets.  The
reason is that the line changed by this patch assumes that events are
always within packets.  However, it is possible (since
26fc5aedf "lib: make packets and packet messages optional, disabled by
default") for stream to not use packets.  In that situation, the
`packet` field of `event_msg->event` will be NULL.

Fix it by using `event_msg->event->stream`, which is expected to be the
same thing as `event_msg->event->packet->stream`, in the case where the
stream uses packets.

A test exercising this is added by a following patch in this series.

The stack at the point of the crash is the following:

    #0 0x7f2235db23ab in auto_seek_handle_message /home/smarchi/src/babeltrace/src/lib/graph/iterator.c:1419
    #1 0x7f2235db330a in find_message_ge_ns_from_origin /home/smarchi/src/babeltrace/src/lib/graph/iterator.c:1567
    #2 0x7f2235db4b1a in bt_message_iterator_seek_ns_from_origin /home/smarchi/src/babeltrace/src/lib/graph/iterator.c:1790
    #3 0x7f2230abf6a4 in state_seek_initially /home/smarchi/src/babeltrace/src/plugins/utils/trimmer/trimmer.c:1095
    #4 0x7f2230ac2f3b in trimmer_msg_iter_next /home/smarchi/src/babeltrace/src/plugins/utils/trimmer/trimmer.c:1920
    #5 0x7f2235dae530 in call_iterator_next_method /home/smarchi/src/babeltrace/src/lib/graph/iterator.c:808
    #6 0x7f2235daefc6 in bt_message_iterator_next /home/smarchi/src/babeltrace/src/lib/graph/iterator.c:855
    #7 0x7f2230d1b458 in details_consume /home/smarchi/src/babeltrace/src/plugins/text/details/details.c:476
    #8 0x7f2235da3d61 in consume_graph_sink /home/smarchi/src/babeltrace/src/lib/graph/graph.c:456
    #9 0x7f2235da40e0 in consume_sink_node /home/smarchi/src/babeltrace/src/lib/graph/graph.c:498
    #10 0x7f2235da4875 in consume_no_check /home/smarchi/src/babeltrace/src/lib/graph/graph.c:572
    #11 0x7f2235da510b in bt_graph_run /home/smarchi/src/babeltrace/src/lib/graph/graph.c:636
    #12 0x563a71c8127a in cmd_run /home/smarchi/src/babeltrace/src/cli/babeltrace2.c:2503
    #13 0x563a71c8218a in main /home/smarchi/src/babeltrace/src/cli/babeltrace2.c:2691
    #14 0x7f22351f2b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #15 0x563a71c73709 in _start (/home/smarchi/build/babeltrace/src/cli/.libs/babeltrace2+0x1f709)

Change-Id: Ic7ed3927d5ad1ca04833248a97723f0d8c4e4907
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3104
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: correct typo in README

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

fix: Remove empty python bindings documentation

The python bindings documentation doesn't exist yet but the build system
contains remnants of the bt1 doc. Moreover, it contains a Sphinx theme
without any copyright or licensing information which makes our distro
friends a bit nervous.

Remove everything for now, it can be re-introduced when the doc is
actually written.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I11b23822c8bf98c54a88c7e856d606d01102797f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2941
Reviewed-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

plugin-so.c: add comment about why we're not using a GLib linked list

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2e05156289d0d66a0a6ed9610d9d88a827a0b357
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2939

README: Babeltrace 2 was released in 2020

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I98b628edf257982fe42143f109a9d785424f7252
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2867

fix: set autoconf package name to babeltrace2

This will help to make sure we are co-installable with babeltrace 1 by
moving the documentation directory to '/usr/share/doc/babeltrace2'.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Ia55d2049967016fc5a00594c928e0f2c4f0e477d
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2858
Reviewed-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Typo: occured -> occurred

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I57d85deda90603e5c2824b8e0d4d07c71ca291db
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2859
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

.gitignore: Add missing bt2/native_bt.d

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Ia0619ac791fb06f3fbbb414a75fcd145eb9f9d70
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2901
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

fix: build failure on ppc64el with '-Werror=format-overflow='

Enabling optimizations makes gcc inline bt_plugin_so_shared_lib_handle_create
into bt_plugin_so_create_all_from_static.  That call site passes path == NULL,
so gcc notices that the argument to %s will always be NULL. This is
undefined behavior even if glibc will print "(null)".

Passing NULL to this function just means that we are loading the static
plugins, built-in Babeltrace.  So there's no path to a shared object file,
in this case explicitly print "(null)".

In file included from ../../../src/lib/logging.h:35,
                 from plugin-so.c:27:
In function ‘bt_plugin_so_shared_lib_handle_create’,
    inlined from ‘bt_plugin_so_create_all_from_static’ at plugin-so.c:1393:11:
../../../src/logging/log.h:811:6: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
  811 |      _bt_log_write_d(_BT_LOG_SRCLOC_FUNCTION, __FILE__, __LINE__, \
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  812 |        lvl, tag, __VA_ARGS__); \
      |        ~~~~~~~~~~~~~~~~~~~~~~
../../../src/logging/log.h:897:4: note: in expansion of macro ‘BT_LOG_WRITE’
  897 |    BT_LOG_WRITE(BT_LOG_INFO, _BT_LOG_TAG, __VA_ARGS__)
      |    ^~~~~~~~~~~~
plugin-so.c:174:2: note: in expansion of macro ‘BT_LOGI’
  174 |  BT_LOGI("Creating shared library handle: path=\"%s\"", path);
      |  ^~~~~~~
plugin-so.c: In function ‘bt_plugin_so_create_all_from_static’:
plugin-so.c:174:50: note: format string is defined here
  174 |  BT_LOGI("Creating shared library handle: path=\"%s\"", path);
      |                                                  ^~
In file included from ../../../src/lib/logging.h:35,
                 from plugin-so.c:27:
In function ‘bt_plugin_so_shared_lib_handle_create’,
    inlined from ‘bt_plugin_so_create_all_from_static’ at plugin-so.c:1393:11:
../../../src/logging/log.h:811:6: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
  811 |      _bt_log_write_d(_BT_LOG_SRCLOC_FUNCTION, __FILE__, __LINE__, \
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  812 |        lvl, tag, __VA_ARGS__); \
      |        ~~~~~~~~~~~~~~~~~~~~~~
../../../src/logging/log.h:897:4: note: in expansion of macro ‘BT_LOG_WRITE’
  897 |    BT_LOG_WRITE(BT_LOG_INFO, _BT_LOG_TAG, __VA_ARGS__)
      |    ^~~~~~~~~~~~
plugin-so.c:217:3: note: in expansion of macro ‘BT_LOGI’
  217 |   BT_LOGI("Created shared library handle: path=\"%s\", addr=%p",
      |   ^~~~~~~
plugin-so.c: In function ‘bt_plugin_so_create_all_from_static’:
plugin-so.c:217:50: note: format string is defined here
  217 |   BT_LOGI("Created shared library handle: path=\"%s\", addr=%p",
      |                                                  ^~
cc1: all warnings being treated as errors

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Ia727b37b04cb10f29e705f21c6889035a304a822
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2894
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

Silence -Wnull-dereference warning in generated CTF parser code

Building Babeltrace on amd64 with -O3 on Ubuntnu 18.04 (gcc
7.4.0-1ubuntu1~18.04.1), I see:

  make[1]: Entering directory '/home/smarchi/build/babeltrace-opt/src/plugins/ctf/common/metadata'
    CC       libctf_parser_la-lexer.lo
  /home/smarchi/src/babeltrace/src/plugins/ctf/common/metadata/lexer.c: In function ‘yyrestart’:
  /home/smarchi/src/babeltrace/src/plugins/ctf/common/metadata/lexer.c:1997:20: error: potential null pointer dereference [-Werror=null-dereference]
    b->yy_fill_buffer = 1;
    ~~~~~~~~~~~~~~~~~~^~~

This is code generated by flex, there's not much we can do, so silence
the warning for the helper library that contains the lexer/parser.

Change-Id: I6698a73f50e88cb75b94ca80deec0f3a9556c4bf
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2895
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>

doc: graph.h: do not link to `man7.org` for `babeltrace(1)`

This website uses the project's upstream repository to find its manual
pages:

> This page was obtained from the project's upstream Git repository
> ⟨git://git.efficios.com/babeltrace.git⟩ on 2019-05-09.

At that date, the Babeltrace 2 CLI's name was still `babeltrace`, so
<http://man7.org/linux/man-pages/man1/babeltrace.1.html> is actually an
old Babeltrace 2 CLI manual page.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2a449dd3afee25dfb87993ee0d653f717b109c99
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2870

Update working version to Babeltrace 2.1.0-rc1

This is not the _release_ commit of Babeltrace 2.1.0-rc1; it merely
updates the current working version to 2.1.0-rc1.

Since this commit is not tagged, the `git describe`
output (e.g. v1.2.0-3402-g836e3fd0d) will be included as part of the
library's "development stage" version field.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ia868892bd611ff11bba5b01399a78f6cb5c7f6c2
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2845
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

fix: common/list.h is LGPL-2.1

Add 'lgpl-2.1.txt' to the distribution tarball and correct the path to
list.h in LICENSE.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I7b3612b47da52170fc5fc2da3d38115152adcdbd
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2853
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

fix: build Python bindings with GCC10

Disable -Wnull-dereference for native_bt.c

bt2/native_bt.c: In function ‘SWIG_Python_NewPointerObj.constprop’:
bt2/native_bt.c:2207:13: error: potential null pointer dereference [-Werror=null-dereference]
 2207 |   PyObject *newraw = data->newraw;
      |             ^~~~~~

Change-Id: I05db1c48304b1fbc715d273425e16d7605405b27
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2852
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

fix: use correct function to print 'enum bt_ctf_scope'

Building with GCC10 results in the following error:

implicit conversion from 'enum bt_ctf_scope' to 'enum bt_field_path_scope' [-Werror=enum-conversion]

Change-Id: Id1144231f8439444696e4683dff2b0abf0d26d60
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2851
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

Release: Babeltrace 2.0.0 "Amqui"

Released at long last!

Adds the name and description of the release.

The ChangeLog is reset as we are starting a new release series afresh.
The ChangeLog of this release describes the changes that were
introduced between the fourth release candidate (rc4) and this
final version of Babeltrace v2.0.0.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id57d79cd0efba4aa0f8c699abe1def190dd841d7
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2844
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>

cli: colorize version printing

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I76388372a3b2f11ebb2ee76020f3d224f376f604
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2840
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

cli: print full version name

Include the release's name and name description, the Git revision
description, and extra information.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I478da57eb24b6a8d0f9c7a0b7b1fb8a41d8e4867
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2839
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

lib: add bt_version_get_extra_{name,description,patch_names}

Those new functions return extra information about the library's version
for custom builds (see `version/README.adoc`).

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I52abca8235826d1e336584285e925147895b13f4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2838
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

lib: add bt_version_get_vcs_revision_description()

For a non-release build, this function returns the Git revision's
description.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Iec5e5fb1bb220c3477bfecab3c3f35b103c0592e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2837
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

common: support custom, extra information for build's version

This patch adds a system of extra version information also found in
LTTng-tools.

`src/common/Makefile` generates `src/common/version.i` at every build.
This file contains:

* The current Git revision description.

* Extra name of the version (found in `version/extra_version_name`).

* Extra description of the version (found in
  `version/extra_version_description`).

* A list of patch file names found in `version/extra_patches`.

All definitions can be empty strings.

See `version/README.adoc` to learn more.

As of this patch, libbabeltrace2 does not offer getters for this data
and the CLI does not print it with the `--version` option. This is
reserved for subsequent patches.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ife50e5bcaa6b3bdeda6ee4e7c1fdeb2fb1f63887
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2836
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

configure.ac, lib: rename "extra" (version) to "development stage"

"Extra" is a term which we'll use for something else brought by a
subsequent patch.

I took the "development stage" term from
<https://en.wikipedia.org/wiki/Software_release_life_cycle#Stages_of_development>,
where "Release candidate" is one of the stages.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I285fbf9851cde41a520079b4c31cdc5d8bf32412
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2835
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

lib: add bt_version_get_name() and bt_version_get_name_description()

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: If080c93994ac5869e29061b21d7b5c35387985d3
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2834
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

lib: bt_version_get_extra(): return `NULL` if none instead of empty str.

This follows the pattern we have for other optional strings returned by
the library.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I775f4f3be917bde405ad3b5e63183dae9609cf03
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2833
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

configure.ac: add version name/description definitions and report them

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: If287cce862facaaec71c63030ae578e24bcf4591
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2832
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

Document libbabeltrace2's C API

This patch adds initial documentation for the Babeltrace 2 library's
C API using Doxygen.

The Doxygen project is located in `doc/api/libbabeltrace2`, as we can
eventually add `doc/api/libbabeltrace2-ctf-writer`.

To be able to use Doxygen's member grouping [1], I had to join some
header files (`const` and non `const` headers, for example), because
otherwise I could not get some functions in separate files to be in the
same member group in the order I want. In the end, the library user
includes `<babeltrace2/babeltrace.h>`, so how we organize the headers
exactly is not so crucial.

[1]: http://www.doxygen.nl/manual/grouping.html#memgroup

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I6d1dc2e7c5ee63fcd4220d0fd9f0931d361d2f31
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2807
Tested-by: jenkins <jenkins@lttng.org>

Fix: src.ctf.lttng-live: emitting stream end msg with no stream

Background
==========
When a stream hangs up on the `src.ctf.lttng-live` component, we make
sure we send a stream end message to ensure we honor The Contract which
states that any stream beginning must eventually be followed by its
stream end counterpart. We do this by calling
`ctf_msg_iter_get_next_message()` one last time to emit any missing
messages.

Using the upcoming lttng clear feature in conjunction with a per-pid
session makes it highly likely that a live stream hangs up on the
`src.ctf.lttng-live` component between the moment we learn about it and
the moment we first ask for its live index.

In such event, the live stream iterator and its `ctf_msg_it` are both
created but the corresponding stream is uninitialized.

When the component realized that a live stream has hung up, it calls
`ctf_msg_iter_get_next_message()` to respect The Contract but then
errors out here:
  CAUSED BY [lttng-live: 'source.ctf.lttng-live'] (msg-iter.c:2474)
    Cannot create stream end message because stream is NULL:
    msg-it-addr=0x555fba864010

The `stream` field is null because we never got the chance to received
any index for this stream.

Issue
=====
It's possible for a `ctf_msg` state machine to pass by the
`STATE_EMIT_MSG_STREAM_END` state without having passed by the
`STATE_EMIT_MSG_STREAM_BEGINNING` state.

Solution
========
Keep track of the fact that we sent a stream beginning message
downstream and that we need to send its respective stream end message.
If no message were send for a particular stream, we can omit sending a
stream end message.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: If7f52f43162e7263785713c01c226907fe475d94
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2719
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

lib: msg. iter. inactivity message has a simple CS, not a default CS

The "default clock snapshot" properties of some types of messages come
from the fact that a stream class has a default clock class, and
therefore its streams have a default clock.

A message iterator inactivity message is not related to any stream, so
it doesn't have a "default" clock class: it has a simple clock class,
and therefore a simple clock snapshot.

Update the C and Python APIs to show this.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I0142c4f91217791e3157d37a32f4e2f234afa8d2
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2801
Tested-by: jenkins <jenkins@lttng.org>

lib: remove self component param. from msg. iterator init. method

Since a3f0c7db ("lib: introduce bt_message_iterator_class"), the
`self_component` parameter of
`bt_message_iterator_class_initialize_method` is useless because you can
access the equivalent with bt_self_message_iterator_borrow_component().

Remove it.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I81e967acfd99b6ef3a2e01ae2ee19008a3c60408
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2761
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

lib: graph API: return borrowed references when adding to an object

Before this patch, the following functions return a new reference when
their last parameter is not `NULL`:

* bt_graph_add_filter_component()
* bt_graph_add_filter_component_with_initialize_method_data()
* bt_graph_add_simple_sink_component()
* bt_graph_add_sink_component()
* bt_graph_add_sink_component_with_initialize_method_data()
* bt_graph_add_source_component()
* bt_graph_add_source_component_with_initialize_method_data()
* bt_graph_connect_ports()
* bt_self_component_filter_add_input_port()
* bt_self_component_filter_add_output_port()
* bt_self_component_sink_add_input_port()
* bt_self_component_source_add_output_port()

I'm changing this so that they return a borrowed reference instead. This
is more in line with other non-creating functions which always return
borrowed references.

It's okay to borrow here because the object to which you add an object
becomes its owner anyway.

Most sites are updated by removing the *_put_ref() call as the reference
is now borrowed.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I71a5e18760504d8f8610162e3f6d7bd8d87474f9
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2762
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

lib: plugin-dev.h: rename `MESSAGE_ITERATOR` -> `MESSAGE_ITERATOR_CLASS`

This is more in line with the message iterator class concept and
indicates that a given method belongs to the (implicit) component
class's message iterator class.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Icbcefec886fcbb2b1928d4b1009f3aca88c032a0
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2751
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

lib: rename "self comp. input port message iter." -> "message iterator"

This simplifies the terminology (and therefore the eventual
documentation). It's possible because we have a single type of message
iterator since 6c373cc9 ("lib: remove output port message iterator").

I just moved everything in
`self-component-port-input-message-iterator.h` to `message-iterator.h`
and removed the specific prefix. Header files are about to be reshaped
soon anyway with the C API documentation patch.

In the Python API, I changed *._create_input_port_message_iterator() to
*._create_message_iterator(). I didn't change
`_UserComponentInputPortMessageIterator` because it's not a public name,
so it's not critical to change it now.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I219b25495911363595bdf3b8b3f3b3cf802f20ac
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2749
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

lib: append `_FUNC` to `BT_PLUGIN_{INITIALIZE,FINALIZE}*`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ie643815f2ec07149025d864324e6aefc55a14cd5
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2750
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

Replace `diamon.org/babeltrace` with `babeltrace.org`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I87e6b0722358d74a0377b6b3f37ed81d65aeaa8c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2747

lib: create common base for bt_component_class_{source,filter}

There are multiple spots which deal with message iterators, that have
duplicated code for source and filter components.  The code is the same,
except that one side deals with a bt_component_class_source and the
other with a bt_component_class_filter.

This patch introduce a common base,
bt_component_class_with_iterator_class, that holds the message iterator
class property.  The aforementioned code paths can then be deduplicated.

Change-Id: Ib2b42da4e77a0ab7faf94533684a7c1d665eb2e9
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2744
Tested-by: jenkins <jenkins@lttng.org>

lib: introduce bt_message_iterator_class

Today, when defining a source or filter component class, the user sets
the message iterator methods directly on the class.  The `next`
methods is mandatory, so it is passed to
bt_component_class_{source,filter}_create, and the rest are optional, so
they are set by dedicated setters.  All these setters are therefore
duplicated for source and filter, for example:

  - bt_component_class_source_set_message_iterator_initialize_method
  - bt_component_class_filter_set_message_iterator_initialize_method

This patch factorizes everything related to message iterator methods and
introduces the concept of "message iterator class".  Instead of setting
the message iterator methods on a component class, the user will now
prepare a message iterator class, and pass a reference to this class
when creating a source or filter component class.  So, what used to be
this:

    src_cls = bt_component_class_source_create(my_iter_next_method);
    bt_component_class_source_set_message_iterator_initialize_method(my_iter_init_method);

would now become:

    iter_cls = bt_message_iterator_class_create(my_iter_next_method);
    bt_message_iterator_class_set_initialize_method(my_iter_init_method);
    src_cls = bt_component_class_source_create(iter_cls);

The message iterator class is a ref-counted object, and
bt_component_class_{source,filter}_create take their own references, so
a user would typically call bt_message_iterator_class_put_ref just after
that, as they would likely have no more use for the iterator class.  It
would be possible, in theory, to share an iterator class between
multiple component classes, but to this day no practical usage has been
found.  The search continues.

The macros to define a component class in a plugin remain the same,
where the message iterator methods are attached to the component class.
For example

    BT_PLUGIN_SOURCE_COMPONENT_CLASS_MESSAGE_ITERATOR_INITIALIZE_METHOD_WITH_ID

In other words, the message iterator class concept is not exposed in
this area.

There is a small change on the message iterator `initialize` methods
impacting existing components: the `initialize` method of
`bt_message_iterator_class` accepts a `bt_self_component` instead of a
specialized `bt_self_component_source` or `bt_self_component_filter`.
If the `initialize` method requires the specialized version, the
user should pass it through the user data attached to the component.
This had to be changed in the debug info component, for example.

Change-Id: Idf8666d028eadae34589cc0460dc1da19ca75765
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2725
Tested-by: jenkins <jenkins@lttng.org>

lib: run most of bt_self_component_port_input_message_iterator_try_finalize when iterator is in NON_INITIALIZED state

We hit a failed BT_ASSERT in the specific scenario explained below (and
illustrated by the new test).

The problem
-----------

Let's say we have a graph with this topology, where everything is
implemented in Python:

  MySink [in] <-> [out] MyFilter (MyFilterIter) [in] <-> [out] MySource (MySourceIter)

And the following sequence of events:

1. MySink's _user_graph_is_configured method creates an iterator on its
   "in" input port.  This runs MyFilterIter's __init__ method.
2. MyFilterIter's __init__ method starts by creating an upstream
   iterator on its "in" input port.  This iterator, of type
   MySourceIter, is initialized successfully.
3. MyFilterIter's __init__ method creates some other data structure which
   happens to form a Python reference cycle (the MyFilterIter instance has a
   reference on an object, which has a reference on the MyFilterIter
   instance).
4. MyFilterIter's __init__ method encounters an error, so an exception
   is raised.

When the MySourceIter is created, an entry is added to MyFilterIter's
upstream_msg_iters array (in the underlying
bt_self_component_port_input_message_iterator object).

When the exception is raised, because of the reference cycle, the
MyFilterIter Python object stays alive.  It has a reference on the
MySourceIter Python object, which keeps the underlying
bt_self_component_port_input_message_iterator object alive as well.

When the create_self_component_input_port_message_iterator call realizes
that the initialization of the filter iterator failed, it does a put_ref
on the iterator object, which ends up calling
bt_self_component_port_input_message_iterator_destroy.  In there, we
assert that:

  BT_ASSERT(iterator->upstream_msg_iters->len == 0);

This assertion does not hold, because the array still contains the entry
for the upstream iterator (on MySource).

Normally, the call to
bt_self_component_port_input_message_iterator_try_finalize, earlier in
bt_self_component_port_input_message_iterator_destroy, should take care
of unlinking any upstream or downstream iterator.  However, that step is
completely skipped because the iterator is still in the NON_INITIALIZED
state.

To reproduce, it is important to have the two conditions before the
exception is raised:

  - an upstream iterator is created: otherwise, the upstream_msg_iters
    array is empty so the assertion is true
  - a Python reference cycle exists, keeping the MyFilterIter object
    alive: otherwise, it is destroyed when the exception is raised (or
    caught?), which destroys the MySourceIter object, which destroys the
    underlying bt_self_component_port_input_message_iterator object (or
    the source iterator), which removes itself from the filter
    iterator's upstream_msg_iters array.  The array now being empty, the
    assertion would be true.

Note that the Python reference cycle is a user error that is not
desirable, but likely to happen.  To avoid any memory leak due to such a
reference cycle, I think the filter iterator here should normally make
sure to break the reference cycle.  In a successful execution, it would
be in _user_finalize.  If __init__ fails, it should make sure to not
leave a reference cycle in place, perhaps by using a try-except to clear
it before exiting the function.

The fix
-------

I believe it's wrong to skip the _try_finalize function even when we are
in this state, because it's possible (as shown above) for an iterator
initialize method to create some upstream iterators but then fail.  The
iterator remains in the NON_INITIALIZED state, but has some upstream
iterators.

I have changed
bt_self_component_port_input_message_iterator_try_finalize so that when
the iterator is in the NON_INITIALIZED, we do unlink the upstream and
downstream iterators.  However, I don't think we want to call the
iterator's finalize method in that case, since it hasn't been properly
initialized (a bit like a C++ object destructor is not called if the
constructor throws).  So I made it so the finalize method is only called
if the state is not NON_INITIALIZED.

Change-Id: Ibe2cbc729fc81ff0d68219400d925110242b7ae1
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2633
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>

tests: plug memory leak in test_bin_info

When running test_bin_info (e.g. through
tests/plugins/flt.lttng-utils.debug-info/test_bin_info_i386-linux-gnu)
under Valgrind, I get:

==25792== 1,112 (88 direct, 1,024 indirect) bytes in 1 blocks are definitely lost in loss record 18 of 20
==25792==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25792==    by 0x55C2B10: g_malloc0 (gmem.c:129)
==25792==    by 0x55C86F2: g_option_context_new (goption.c:361)
==25792==    by 0x10CB25: main (test_bin_info.c:419)

Fix that by calling g_option_context_free.

Reported-by: Valgrind Memcheck
Change-Id: I9cd9a5ef786484169b9215744861af8cd6f5a9c8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2739
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>

debug-info: free existing build-id in bin_info_set_build_id

When running test
tests/plugins/flt.lttng-utils.debug-info/test_bin_info_i386-linux-gnu, I
see:

Direct leak of 20 byte(s) in 1 object(s) allocated from:
    #0 0x7f623da26d38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38)
    #1 0x7f623ce37b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10)
    #2 0x5583ef04ad8f in test_bin_info_build_id /home/smarchi/src/babeltrace/tests/plugins/flt.lttng-utils.debug-info/test_bin_info.c:239
    #3 0x5583ef04bd01 in main /home/smarchi/src/babeltrace/tests/plugins/flt.lttng-utils.debug-info/test_bin_info.c:445
    #4 0x7f623c7f7b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

This is because a build id is set twice on the same bin_info object in
test_bin_info_build_id.  However, bin_info_set_build_id doesn't free the
existing build id, if there is one, before assigning the new build id.

Fix that by freeing the existing build id, if any, before allocating the
new one.

Reported-by: ASan
Change-Id: I66409294bf11accde6c9d54a5e07572f9a995ff6
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2738
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>

cli: free log level string value

In bt_config_convert_from_args, when encoutering a --log-level argument
applied to a non-option argument, we create a string bt_value.  We add
it to an array, which takes its own reference on it.  However, in the
successful case, we never drop our reference to it, so it's never freed.
Fix it by calling bt_value_put_ref on it in all cases.

This is the error reported by address sanitizer:

Direct leak of 128 byte(s) in 2 object(s) allocated from:
    #0 0x7f1e36724d38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38)
    #1 0x7f1e35d97b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10)
    #2 0x558c39c19d3b in bt_config_convert_from_args /home/smarchi/src/babeltrace/src/cli/babeltrace2-cfg-cli-args.c:3445
    #3 0x558c39c1f9e4 in bt_config_cli_args_create /home/smarchi/src/babeltrace/src/cli/babeltrace2-cfg-cli-args.c:4654
    #4 0x558c39c233db in bt_config_cli_args_create_with_default /home/smarchi/src/babeltrace/src/cli/babeltrace2-cfg-cli-args-default.c:74
    #5 0x558c39c0781a in main /home/smarchi/src/babeltrace/src/cli/babeltrace2.c:2647
    #6 0x7f1e35757b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Reported-by: ASan
Change-Id: Ib2251d9dd8628bda128ae4d2e756d0d86fa12163
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2737
Tested-by: jenkins <jenkins@lttng.org>

bt2: free port user data when finalizing components

When creating component ports in Python, it is possible to pass a Python
object as user data:

    class MySource(
        bt2._UserSourceComponent, message_iterator_class=MyIter
    ):
        def __init__(self, config, params, obj):
            self._add_output_port('out', MyUserData())

The port takes a reference to this Python object, thanks to the `void *`
typemap in native_bt_port.i:

    %typemap(out) void * {
            Py_INCREF($1);
            $result = $1;
    }

However, this reference is never released.

This patches makes it so that when a component is finalized, it releases
the reference for the user data of all of its ports.

Change-Id: Ifebecc3b242c2ccf2bd65347a9087b90093f286c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2734
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

build: try calling python-config with --embed

To get the flags required to link an application with Python 3.8 (such
as to embed Python in the application), it is necessary to use the
"--embed" flag of python-config.  These flags include "-lpython3.8".
Without "--embed", the printed flags are for building a Python
extension.  These don't require being linked with the Python library,
since they are dlopen'ed by the library itself.

Our Python plugin provider requires being linked with Python, since it
embeds a Python interpreter.  Since we don't use "--embed" currently
when getting link flags, we don't link with the Python library, and
therefore the provider is not usable with Python 3.8.

The solution proposed here:

  https://docs.python.org/3/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build

is to try calling python-config with --embed first, and then without if
that didn't work.  With this patch, I am able to use the Python plugin
provider with Python 3.8.

Change-Id: I0c0e61dd3bded853abf124c651efe98ee7700101
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2726
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>

tests: remove unnecessary message iterator classes

These user message iterator classes don't do anything special, we can
remove them and pass bt2._UserMessageIterator directly to the components
instead, reducing a little bit the noise in the tests.

Some classes in test_component_class.py were simply unused, so I removed
them.

Change-Id: I79f787b9d121a3dc6456f81090ebf51d088d2c73
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2736
Tested-by: jenkins <jenkins@lttng.org>

tests: make test_sink_self_port_user_data actually test a sink

This test method is meant to test a sink, but currently tests a filter,
fix that.

Change-Id: Icca321f50a43b709b64f15c885c37c6e7106653d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2735
Tested-by: jenkins <jenkins@lttng.org>

lib: remove unnecessary (void *) cast in extend_map_element

Change-Id: I238aeef707d2822030c18e2a8dc1ebf4d432a9f2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2732
Tested-by: jenkins <jenkins@lttng.org>

cli: fix bt_plugin leak when using `-i ctf`

When running:

    libtool --mode=execute valgrind --leak-check=full  ./src/cli/babeltrace2 /home/smarchi/src/babeltrace/tests/data/ctf-traces/succeed/succeed1 -i ctf

I get:

    2,680 (168 direct, 2,512 indirect) bytes in 1 blocks are definitely lost in loss record 56 of 58
       at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
       by 0x5360B10: g_malloc0 (gmem.c:129)
       by 0x4E97502: bt_plugin_create_empty (plugin.h:178)
       by 0x4E9AD72: bt_plugin_so_create_empty (plugin-so.c:1239)
       by 0x4E9B0D1: bt_plugin_so_create_all_from_sections (plugin-so.c:1342)
       by 0x4E9BFBF: bt_plugin_so_create_all_from_file (plugin-so.c:1678)
       by 0x4E93FB4: bt_plugin_find_all_from_file (plugin.c:210)
       by 0x4E95300: nftw_append_all_from_dir (plugin.c:551)
       by 0x5956F13: process_entry (ftw.c:464)
       by 0x59573BA: ftw_dir (ftw.c:543)
       by 0x5957BEB: ftw_startup (ftw.c:768)
       by 0x4E95748: bt_plugin_create_append_all_from_dir (plugin.c:641)

The call to find_loaded_plugin at babeltrace2-cfg-cli-args.c:4013
returns a new reference to the plugin, for which we don't have a
corresponding put_ref.

Looking at all the users of find_loaded_plugin, they only really need to
borrow the plugin, so rather than add a put_ref, I've made it so
find_loaded_plugin returns a borrowed reference instead of a new
reference.  For clarity, I've renamed that function to
borrow_loaded_plugin_by_name.  And for consistency, I've renamed
borrow_loaded_plugin to borrow_loaded_plugin_by_index.

Change-Id: I19234bda6e219efa3e55da760846d138c381fac4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reported-by: Valgrind Memcheck
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2731
Tested-by: jenkins <jenkins@lttng.org>

cli: remove unused structures and enums

These have apparently been unused for a while, since:

    commit db0f160afd671de44e52d2b364de957ddccdac02
    Author: Philippe Proulx <eeppeliteloop@gmail.com>
    Date:   Fri Mar 3 00:13:36 2017 -0500

        CLI: add `run` command and make `convert` command use it

Change-Id: Ib8ce061540a0c268d3949a565c570142f37e123c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2728
Tested-by: jenkins <jenkins@lttng.org>

tests: fix test failure with msys2's Python 3.8.1-1 package

msys2's Python package version 3.8.1-1 produces wrong output for
PureWindowsPath's string representation.  It does this:

    >>> import pathlib
    >>> str(pathlib.PureWindowsPath('/yo/madame'))
    '/yo/madame'

When it should do this:

    >>> import pathlib
    >>> str(pathlib.PureWindowsPath('/yo/madame'))
    '\\yo\\madame'

Because of this, tests/plugins/src.ctf.fs/query/test_query_trace_info.py
is currently failing, as the Babeltrace output contains back-slashes but
the regex we produce contains forward-slashes.

The issue appears to be fixed in 3.8.1-2:

    https://github.com/msys2/MINGW-packages/commit/7ce8394ec8af3bdef83d1a24fd9a96bf8da3c154#diff-8b71128fa8f1e4e070196eeb2fc9a19d

But anyway, it's not really necessary to use PureWindowsPath and
PurePosixPath.  I changed the code to just use a version of the regex
with back-slashes when on Windows, and with front-slashes when on the
others.

Change-Id: Idcd865d87350682644a536ada95cfac161cc1182
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2733
Tested-by: jenkins <jenkins@lttng.org>

trimmer: free GMatchInfo object in set_bound_from_str

When a call to compile_and_match succeeds, it returns an allocated
GMatchInfo object in `*match_info`, which is never freed, causing a
memory leak:

    ==3711000== 508 (72 direct, 436 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 42
    ==3711000==    at 0x483AB65: calloc (vg_replace_malloc.c:762)
    ==3711000==    by 0x49CB7C1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.6200.4)
    ==3711000==    by 0x49BCEAA: ??? (in /usr/lib/libglib-2.0.so.0.6200.4)
    ==3711000==    by 0x49BD310: g_regex_match_full (in /usr/lib/libglib-2.0.so.0.6200.4)
    ==3711000==    by 0x49BDEEA: g_regex_match (in /usr/lib/libglib-2.0.so.0.6200.4)
    ==3711000==    by 0x510CF25: compile_and_match (trimmer.c:187)
    ==3711000==    by 0x510D55D: set_bound_from_str (trimmer.c:378)
    ==3711000==    by 0x510D90A: set_bound_from_param (trimmer.c:463)
    ==3711000==    by 0x510DEBE: init_trimmer_comp_from_params (trimmer.c:568)
    ==3711000==    by 0x510E090: trimmer_init (trimmer.c:643)
    ==3711000==    by 0x4886457: add_component_with_init_method_data (graph.c:971)
    ==3711000==    by 0x4886C28: bt_graph_add_filter_component_with_initialize_method_data (graph.c:1075)

Fix that by calling g_match_info_free at the end of the function.

Reported-by: Valgrind Memcheck
Change-Id: Iee42f63d45f5761e1191dcc6d3f6d47e75a4123c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2727
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>

bt2: rename `object` parameter -> `object_name`

I think it's more evident this way.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I20f80ab8b28c4f4f0d390dd9fb4676ff69e8e609
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2712
Tested-by: jenkins <jenkins@lttng.org>

lib: remove bt_query_executor_interrupt, add bt_query_executor_borrow_default_interrupter

It is currently possible to interrupt a running quer executor with
bt_query_executor_interrupt.  It is however not possible to reset the
default interrupter that this function sets and resume the query
execution.

Rather than add a new query executor function to reset the default query
executor interrupter, introduce a new function,
bt_query_executor_borrow_default_interrupter, to borrow that default
interrupter.  All the bt_interrupter API is therefore accessible with
this default interrupter.

This patch removes the bt_query_executor_interrupt function, since it's
no longer needed.

Change-Id: I877dfbf22e36233750a71220fc5ab0297f8c0c28
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2709
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

lib: remove bt_graph_interrupt, add bt_graph_borrow_default_interrupter

It is currently possible to interrupt a running graph with
bt_graph_interrupt.  It is however not possible to reset the default
interrupter that this function sets and resume the graph execution.

Rather than add a new graph function to reset the default graph
interrupter, introduce a new function,
bt_graph_borrow_default_interrupter, to borrow that default interrupter.
All the bt_interrupter API is therefore accessible with this default
interrupter.

This patch removes the bt_graph_interrupt function, since it's no longer
needed.

Change-Id: I277e6c8bb4e1be0a6557a6287b7ba8997e20d27b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2708
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

lib: graph API: remove "listener removed" callback parameters

Before this patch, when you add a "port added" listener to a graph,
you can pass a callback which gets called when the listener is removed.
This only happens when the graph is destroyed.

This "listener removed" callback feature seems unnecessary as the graph
user, who adds the "port added" listener, has total control over the
graph object. Therefore she can ensure that anything needed by her "port
added" listeners exists as long as the graph exists.

Therefore this patch removes those parameters and everything related.

In Python, we used to keep a strong reference on the partial Python
object (listener's data) and release it when our "listener removed"
function was called. Now, the listener's data is a weak reference, but
we keep a list of strong partial references within the graph object
itself (`self._listener_partials`) to ensure that the partials exist as
long as the graph exists.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I4c06ff139740f887ae2ace7633d2edeb01fd2fa0
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2637
Tested-by: jenkins <jenkins@lttng.org>

lib, bt2: graph API: remove "ports connected" listeners

Two ports being connected is always the consequence of the graph user
calling bt_graph_connect_ports() and this function returning
`BT_GRAPH_CONNECT_PORTS_STATUS_OK`. In other words, this event cannot
occur without a direct, concomitant action by the graph user.

Knowing this, the "ports connected" graph listeners are useless.

The "port added" listeners remain useful: a component can add a port at
many moments during the graph configuration phase, therefore having a
"port added" listener can avoid checking if the current graph components
have new ports every time you call bt_graph_add_*_component*() or
bt_graph_connect_ports().

This patch removes everything related to the "ports connected" graph
listeners.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I218c7b7b57c52f2e8589b35e3d89f38dfd961c0a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2636
Tested-by: jenkins <jenkins@lttng.org>

babeltrace2-plugin-ctf(7): "theirs" -> "its" (single CTF trace)

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I251e8c5c2a357637983be92abb597827ffadd7da
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2640

.gitignore: add missing `/tests/lib/test_remove_..._destruction_listener`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I20a520668a9f2bff7c47891072f907fd2b53d9e6
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2635
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

Sync argpar with upstream

Sync with commit:

    92ecd98e487729d7ec268a986390b624fc394feb
    Add missing va_end in argpar_vasprintf

Change-Id: If005cbc043af96e4db9ad4d1a8b2d341944383d0
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2624

Use argpar from upstream

Now that argpar is maintained in a separate repository, sync the code
with it and remove tests from this code base.

The code was sync'ed  with the argpar repository at commit:

    f46b510674785c70781a3de06c02888faded5db9 (HEAD -> master,
    Strip trailing spaces

Change-Id: Ie805db224f2d3890decbed26a1c80c105d083293
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2616