Release: Babeltrace 2.0.3 "Amqui"

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

Fix: lib: use appropriate format specifier to print message iterator class

Running

  babeltrace2 --debug /some/trace

... results in the following crash:

    ==31705==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f5b9c25ae22 bp 0x7ffc64114490 sp 0x7ffc64113ba8 T0)
    ==31705==The signal is caused by a READ memory access.
    ==31705==Hint: address points to the zero page.
        #0 0x7f5b9c25ae21  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xfce21)
        #1 0x7f5b9c1d231f  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x7431f)
        #2 0x7f5b9c1fef4d in __interceptor_vsnprintf (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xa0f4d)
        #3 0x7f5b9c1ff286 in snprintf (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xa1286)
        #4 0x7f5b9bdf61c3 in format_component_class /home/smarchi/src/babeltrace/src/lib/lib-logging.c:1061
        #5 0x7f5b9bdfad46 in handle_conversion_specifier_bt /home/smarchi/src/babeltrace/src/lib/lib-logging.c:1451
        #6 0x7f5b9bead260 in bt_common_custom_vsnprintf /home/smarchi/src/babeltrace/src/common/common.c:1727
        #7 0x7f5b9bdfb10b in bt_lib_log /home/smarchi/src/babeltrace/src/lib/lib-logging.c:1496
        #8 0x7f5b9be32965 in bt_message_iterator_class_set_seek_beginning_methods /home/smarchi/src/babeltrace/src/lib/graph/message-iterator-class.c:138
...

This is due to an object being printed with the wrong format specifier.
`C` is for component class objects, use `I` instead, since we are
printing a message iterator object.

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

Fix: sink.text.pretty: check that port is connected before creating message iterator

sink.text.pretty does not check if its input port is connected before
trying to create a message iterator on it.  This can lead to a
precondition assertion failure.  It can be reproduced with this Python
snippet.

    import bt2
    g = bt2.Graph()
    g.add_component(bt2.find_plugin('text').sink_component_classes['pretty'], 'snk')
    g.run()

The assertion failure we get is:

    04-14 11:35:27.339 1231815 1231815 F LIB/MSG-ITER create_self_component_input_port_message_iterator@iterator.c:295 Babeltrace 2 library precondition not satisfied; error is:
    04-14 11:35:27.339 1231815 1231815 F LIB/MSG-ITER create_self_component_input_port_message_iterator@iterator.c:295 Input port is not connected: port-addr=0x607000001d70, port-type=INPUT, port-name="in"
    04-14 11:35:27.339 1231815 1231815 F LIB/MSG-ITER create_self_component_input_port_message_iterator@iterator.c:295 Aborting...
    ./tests/utils/../utils/utils.sh: line 283: 1231815 Aborted (core dumped) env "${env_args[@]}" "$@"

Add a check and return an error if that happens instead.  A
corresponding test is also added.

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

Add initial Python bindings documentation

This initial documentation contains a home page, an installation page,
and a few examples to understand how the `bt2` package works.

Still missing: how exactly the bindings wrap libbabeltrace2 (wraping
rules, exceptions, etc.).

Changes:

`README.adoc`:
    Specify that you need Sphinx to build the Python bindings
    documentation.

`configure.ac` and `m4/check_sphinx.m4`:
    Add `--enable-python-bindings-doc` which requires
    `--enable-python-bindings`.

    This is because the Sphinx configuration file actually imports the
    `bt2` package to get the version (and, eventually, for Sphinx's
    autodoc to find docstrings within the `bt2` modules).

`doc/bindings/python/source`:
    The actual documentation's contents and configuration.

`doc/bindings/python/ext/bt2sphinxurl.py`:
    A Sphinx extension to add Babeltrace 2 manual page and other links
    of which the URL includes the project's version.

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

Backported from ba64dfcccb1f1bd7a259dc5d563ba422b8375582

Modifications:
 configure.ac:
   PPRINT_PROP_BOOL_CUSTOM -> PPRINT_PROP_BOOL
 examples.rst:
   Removed example usage for `in`:
      if 'next_comm' in event:
    This utility was introduced by
    f03b6364aec2d77bbb5ef0625cbaea8de4179f63, not backported,
    and only provides a shortcut to iterate over all `root` fields.
    User can implement their own as needed.
  Updated referenced version of lttng from 2.11 to "latest" for
  lttng-live url.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: Id0f4636a5f66e98d383548bdcb894f53d31812b4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3408
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

Fix: bt2: read properties on _DiscardedEventsMessage

Reading the count and clock snapshot properties on a _DiscardedEventsMessage
does not work.  For example, this:

    msg = self._create_discarded_events_message(stream, count=10)
    print(msg.count)

Results in:

      File "test.py", line 10, in __init__
        print(msg.count)
      File "/home/simark/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/message.py", line 208, in count
        avail, count = self._get_count(self._ptr)
    AttributeError: '_DiscardedEventsMessage' object has no attribute '_get_count'

The problem is simply that _DiscardedEventsMessage is missing inheriting
from _DiscardedEventsMessageConst.

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

tests: add tests for discarded events/packets creation

Creation of these messages is a bit tested in AllMessagesTestCase, but
not everything, especially not the error cases.

To avoid code duplication as much as possible, I've added a
`run_in_message_iterator_next` helper, similar to the existing
`run_in_component_init`.  This helper takes a callback to run in the
context of a source component's message iterator's __next__method.
Individual tests also need to customize the stream class creation, to
decide if the stream class supports discarded event/packet messages,
clock snapshots on those messages, etc.  So it also receives a callback
executed in the source component's __init__ method, which must return a
stream class.  This callback takes a trace class as a parameter, which
it will need to create the stream class, and a clock class.  It is free
to use the clock class as the stream class' default_clock_class or not.

Doing this, I noticed that reading the count and clock snapshot
properties on a _DiscardedEventsMessage didn't work.  This will be fixed
in a subsequent patch, in the mean time the corresponding assertions are
commented out.

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

Fix: bt2: add precond. check, for stream class supporting discarded msgs with clock snapshot without clock class

We hit the following precondition failure from the Python bindings when
creating a stream class that supports discarded event messages with
clock snapshots, but does not have a default clock class.  Same with
discarded packet messages.

    04-10 16:40:32.280 59345 59345 F LIB/STREAM-CLASS bt_stream_class_set_supports_discarded_events@stream-class.c:480 Babeltrace 2 library precondition not satisfied; error is:
    04-10 16:40:32.280 59345 59345 F LIB/STREAM-CLASS bt_stream_class_set_supports_discarded_events@stream-class.c:480 Stream class has no default clock class: addr=0x60f0000023e0, id=0, is-frozen=0, event-class-count=0, packet-context-fc-addr=(nil), event-common-context-fc-addr=(nil), assigns-auto-ec-id=1, assigns-auto-stream-id=1, supports-packets=0, packets-have-begin-default-cs=0, packets-have-end-default-cs=0, supports-discarded-events=0, discarded-events-have-default-cs=0, supports-discarded-packets=0, discarded-packets-have-default-cs=0, trace-class-addr=0x608000002b20, pcf-pool-size=0, pcf-pool-cap=0
    04-10 16:40:32.280 59345 59345 F LIB/STREAM-CLASS bt_stream_class_set_supports_discarded_events@stream-class.c:480 Aborting...

Add some checks for that in _StreamClass._validate_create_params, and
some corresponding tests.

Change-Id: I5d79b8ecfc05acbb79b7b15d28ba2c5c34f00729
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3390
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit aa7407227594c8e5ebff8e1944a902760f2c9a17)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3364
CI-Build: 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>
(cherry picked from commit 6adf99d540b2d239fc49bb64934becf410812c39)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3363
CI-Build: 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>
(cherry picked from commit c7f21c12d5cec35f3e48630cf603207748409847)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3362
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

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>
(cherry picked from commit c16fb81a23dcfa6ab8331efe1c98a86e4444040d)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3361
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

Revert "bt2: _EventConst.__getitem__(): use a single temporary variable"

I did not want to merge this and pressed the wrong button on Gerrit.

Sorry.

Change-Id: I11cc739c126131560ba31d2a1f3f01b7e961a837
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3354
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: 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/+/3360
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

bt2: _EventConst.__getitem__(): use a single temporary variable

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

Fix: _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/+/3350
Tested-by: jenkins <jenkins@lttng.org>

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/+/3226

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/+/3225

Update working version to Babeltrace 2.0.3

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

Release: Babeltrace 2.0.2 "Amqui"

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

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>
(cherry picked from commit 994cd345db7a82957ce647c2dac28cae11382dcc)

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>
(cherry picked from commit 18961057774c796ea8522db964bc6f03e07a2027)

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>

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>

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

Update working version to Babeltrace 2.0.2

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

Release: Babeltrace 2.0.1 "Amqui"

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

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>

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>
Signed-off-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/+/2940

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/+/2871

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>

Update working version to Babeltrace 2.0.1

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

Since this commit is not tagged, the `git describe`
output (e.g. v2.0.0-1-g7adcb97be) 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: Iad8006929c97d72ebfed7cd683bcaa85c59f9c56

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

bt2: use format_bt_error and format_bt_error_cause to generate _Error and _ErrorCause string representations

This makes it so that formatting bt2._Error as a string looks the same
way as what is printed by the CLI.  It also allows formatting of error
causes individually.

The __str__ methods generate string representations that do not include
terminal color control characters. If we want, we could later add a
"to_string" method that can optionally generate a string with terminal
color control characters.

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

string-format: introduce function to format a bt_error_cause

In the Python bindings, we'll want to be able to format single error
causes.  Factor out the code to format one bt_error_cause from
format_bt_error.

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

string-format: introduce function to format a bt_error

The CLI has a function to format a bt_error nicely.  We will want to use
it in the Python bindings too, so move it to the string-format
convenience library.  Make it return the formatted string instead of
printing directly to stderr.

I did not try to make this function handle memory allocation errors, as:

1. It's not very likely anyway
2. We are likely in the process of handling an error, I don't think it
   would be useful to return an error code.  If something fails in this
   function, I don't know what else remains to do.

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

string-format: introduce function to format component class name

The CLI has a function to print a component class name nicely,
print_plugin_comp_cls_opt.  The same functionality will be needed by
the Python bindings, move the function to a new convenience library.
Modify the function to return a string instead of printing directly to a
stream.  Update users accordingly.

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

common: introduce struct bt_common_color_codes and function bt_common_color_get_codes

The behavior of the color functions is currently initialized at startup.
If we detect that colors should be enabled, we set the
bt_common_color_code_* variables once and for all.

The following patches will introduce string formatting functions that
optionally use color, based on a parameter with three values:

 - always: always use colors, regardless of what we detected at startup
 - never: never use colors, regardless of what we detected at startup
 - auto: use colors based on what we detected at startup

One option would be to add some color functions that take a parameter,
so you could do:

  bt_common_color_bg_cyan_opt(BT_COMMON_COLOR_WHEN_ALWAYS)
  bt_common_color_bg_cyan_opt(BT_COMMON_COLOR_WHEN_NEVER)
  bt_common_color_bg_cyan_opt(BT_COMMON_COLOR_WHEN_AUTO)

However, I find this very verbose, so not very practical.

This patch introduces a new structure type bt_common_color_codes that
holds the color codes for the current terminal, or empty strings.  It
also introduces a function bt_common_color_get_codes that accepts an
always/never/auto parameter.  It initializes a bt_common_color_codes
structure with the color codes (or empty strings) to use.

This will allow the string formatting function to conditionally use
colors without being too verbose:

  struct bt_common_color_codes codes;
  bt_common_color_get_codes(&codes, use_colors);
  printf("%sHello%s\n", codes.fg_cyan, codes.reset);

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

lib: standardize variant field option function names

This patch does the following changes:

bt_field_variant_select_option_field_by_index():
    bt_field_variant_select_option_by_index()

bt_field_variant_get_selected_option_field_index():
    bt_field_variant_get_selected_option_index()

bt_field_variant_borrow_selected_class_option_const():
    bt_field_variant_borrow_selected_option_class_const()

bt_field_variant_with_unsigned_integer_selector_borrow_selected_class_option_const():
    bt_field_variant_with_selector_field_integer_unsigned_borrow_selected_option_class_const()

bt_field_variant_with_signed_integer_selector_borrow_selected_class_option_const():
    bt_field_variant_with_selector_field_integer_signed_borrow_selected_option_class_const()

A variant field is the instance of a variant field class. A variant
field has one or more options which are instances of the variant field
class options. A variant field option contains a field.

The `with_unsigned_integer_selector` to
`with_selector_field_integer_unsigned` and
`with_signed_integer_selector` to `with_selector_field_integer_signed`
renames match what's already in the `bt_field_class` API.

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

bt2: don't print previous causes in causes created from bt2._Error

When an API call from Python fails, we create a bt2._Error that will
take the bt_error from the current thread and assume its ownership.  If
that bt2._Error escapes the Python code and is caught by the Babeltrace
native code, we convert that bt2._Error to a new cause.  We call str()
on the bt2._Error (through bt_py_common_format_exception) to obtain the
text with which to create the new cause.  However, the str() for
bt2._Error textually formats all the existing causes.  As a result, the
text for the new cause includes the string formatting of all the
previous causes.  When the CLI, for example, ends up printing all error
causes successively, it becomes very confusing: the text of one cause
includes the text of previous causes.

What we want, in fact, is not an str() of the bt2._Error, but just a
message that includes the traceback (to know where in the Python code
the cause was created) and the message passed to bt2._Error.__init__.
The traceback is just a goodie: we don't include it for causes created
in C, but since it's easy to obtain in Python it is nice to have.  There
is also the fact the file:line information for causes created in Python
is bogus (which should be fixed at some point), so the traceback fills
in for that for the moment.

This patch changes
restore_current_thread_error_and_append_exception_chain_recursive to
do this for bt2._Error.  For other exceptions, we still call
bt_py_common_format_exception, which ends up calling their __str__.

Here's an example:

    Traceback (most recent call last):
      File "test_simple.py", line 32, in <module>
        graph.run()
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/graph.py", line 188, in run
        utils._handle_func_status(status, 'graph object stopped running')
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/utils.py", line 140, in _handle_func_status
        raise bt2._Error(msg)
    bt2.error._Error: graph object stopped running
    [libbabeltrace2] (/home/smarchi/src/babeltrace/src/lib/graph/graph.c:600)
    Component's "consume" method failed: status=ERROR, comp-addr=0x1f15f50, comp-name="snk", comp-log-level=NONE, comp-class-type=SINK, comp-class-name="DummySink", comp-class-partial-descr="", comp-class-is-frozen=1, comp-input-port-count=1, comp-output-port-count=0
    [snk: sink.DummySink] (/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/native_bt_log_and_append_error.h:99)
    Traceback (most recent call last):
      File "test_simple.py", line 26, in _user_consume
        next(self._iter)
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/message_iterator.py", line 58, in __next__
        status, 'unexpected error: cannot advance the message iterator'
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/utils.py", line 140, in _handle_func_status
        raise bt2._Error(msg)
    bt2.error._Error: unexpected error: cannot advance the message iterator
    [libbabeltrace2] (/home/smarchi/src/babeltrace/src/lib/graph/iterator.c:928)
    Component input port message iterator's "next" method failed: iter-addr=0x1ec1980, iter-upstream-comp-name="src", iter-upstream-comp-log-level=NONE, iter-upstream-comp-class-type=SOURCE, iter-upstream-comp-class-name="SourceWithFailingIter", iter-upstream-comp-class-partial-descr="", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
    [src (out): src.SourceWithFailingIter] (/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/native_bt_log_and_append_error.h:102)
    Traceback (most recent call last):
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/message_iterator.py", line 201, in _bt_next_from_native
        msg = next(self)
      File "test_simple.py", line 8, in __next__
        raise ValueError('User message iterator is failing')
    ValueError: User message iterator is failing

    [libbabeltrace2] (/home/smarchi/src/babeltrace/src/lib/graph/iterator.c:928)
    Component input port message iterator's "next" method failed: iter-addr=0x1ec1980, iter-upstream-comp-name="src", iter-upstream-comp-log-level=NONE, iter-upstream-comp-class-type=SOURCE, iter-upstream-comp-class-name="SourceWithFailingIter", iter-upstream-comp-class-partial-descr="", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
    [src (out): src.SourceWithFailingIter] (/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/native_bt_log_and_append_error.h:102)
    Traceback (most recent call last):
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/message_iterator.py", line 201, in _bt_next_from_native
        msg = next(self)
      File "test_simple.py", line 8, in __next__
        raise ValueError('User message iterator is failing')
    ValueError: User message iterator is failing

Notice how the "ValueError: User message iterator is failing" cause
seems to appear twice?  The first of them is in fact part of the text of
the "bt2.error._Error: unexpected error: cannot advance the message
iterator" cause.  With this patch applied, the first one of these does
not appear.

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

bt2: reverse order of printed causes in _Error.__str__

To match how the CLI prints them.

Change-Id: Ief913b119b169bf9f620531f8763db93e19bda27
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2556
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

bt2: remove ptr parameter of _Error.__init__

It isn't used.  We never pass a bt_error pointer when constructing an
_Error, the constructor of _Error always takes the bt_error from the
current thread.

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

tests: add test for list-plugins CLI command

The test provides a custom Python plugin, then checks for a
corresponding entry in the "list-plugins" output.

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

tests: test removing a destruction listener from a destruction listener

This patch adds a test to verify that removing a trace or trace class
destruction listener from an object from within a destruction listener
of that same object works correctly.

It tests 3 scenarions:

- A destruction listener removing itself.
- A destruction listener removing a destruction listener that was
  already called.
- A destruction listener removing a destruction listener that is not yet
  called.

This assumes that destruction listeners are called in the order in which
there were added.

In the third scenario (removing a destruction listener that is not yet
called), the result is that the removed listener won't get called.

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

tests/lib/Makefile.am: Move libbabeltrace2-common and libbabeltrace2-logging to COMMON_TEST_LDADD

These libraries are necessary to all tests that use BT_ASSERT, which is
the case of pretty much every test.

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

bt2: make _ListenerHandle not hold a strong reference on the target object

The bt2._ListenerHandle object currently holds a strong reference to the
Python object on which the listener was added.  This allows validating
that a handle passed to the remove_destruction_listener method of an
object mathces that object.

However, keeping that strong reference also prevents the destruction of
that target object.  So, adding a destruction listener and keeping the
handle around actually prevents the destruction from happening, making
that destruction listener useless.

Change it so the _ListenerHandle only keeps the address of the target
object.  This is enough to do the check described above.  We must
however invalidate the _ListenerHandle when the target object is
destroyed, because another object could be later created at the same
address.  To achieve this, the handle object is bound to the destruction
callback, so that we can invalidate it in
_trace_destruction_listener_from_native /
_trace_class_destruction_listener_from_native.

The "del" statements in the tests were necessary before, otherwise the
handles would keep the trace class / trace alive, and the destruction
listeners would not get called.  I removed them, so it now tests that
keeping a listener handle doesn't keep the target object alive.

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

bt2: fix error message in trace_class.py

This error message was probably copied from trace.py.  It should say
"trace class" and "trace".

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