git.efficios.com Git - babeltrace.git/log

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

bt2: make Graph add listener methods return None

The methods add_ports_connected_listener and add_port_added_listener of
bt2.Graph currently return a _ListenerHandle object. This is not useful
today, since it's not possible to remove those listeners (unlike trace
class and trace destruction listeners).

Make them not return a handle for now. It will be possible to make them
return a handle again if/when we add the possibility to remove those
listeners.

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

param-parse: allow duplicate map keys

It is a bit odd that this is accepted (the second value overwrites the
first):

-p a=3 -p a=4

but this isn't:

-p a=3,a=4

Remove the check that prevents duplicate keys from being defined in a
map.

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

bt2: validate parameters to _StreamClass.create_event_class before creating the native object

For the same reasons outlined in d3bf1370a437 ("bt2: validate parameters
to _TraceClass.create_stream_class before creating the native object"),
validate the parameters when creating an event class before creating the
native object.

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

bt2: add invalid parameter type test for _UserComponent._create_trace_class

Verify that passing a value of the wrong type to _UserComponent._create_trace_class
produces an error.

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

src.ctf.fs: sort inputs paths

Sort input paths to make the behavior of the component more
deterministic.

For example, when there are duplicated packets in the trace and we pick
one copy, this will ensure that we always process the data stream files in
the same order, and that we always pick the same copy of the packet.

In practice, this will reduce the chances of observing different
behaviors on different platforms where glib reports the files of a trace
in different orders.

A test is added to verify that the choice of which copy of a packet to
choose, in case a packet is present in multiple copies, is independent
from the order of the inputs paths passed to the component.

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

cli: print error causes in all error paths

I noticed that providing a parameter with a wrong syntax to a query
resulted in no error stack shown by the CLI, even though a bunch of
BT_CLI_LOGE_APPEND_CAUSE are done along the way.  We just get the logged
errors:

    ./src/cli/babeltrace2 query -p 'a=2,' src.ctf.fs yo
    11-15 16:17:34.734  6423  6423 E CLI/CFG-CLI-ARGS bt_config_query_from_args@babeltrace2-cfg-cli-args.c:1530 Invalid format for --params option's argument:
        Expecting unquoted map key:

        a=2,
            ^

    11-15 16:17:34.735  6423  6423 E CLI main@babeltrace2.c:2781 Command-line error: retcode=1

This is because the main function only prints the error stack when the
command execution fails, not when anything earlier fails, like the
creation of the command configuration in this case.

Move the call to print_error_causes at the end, so that the causes are
printed every time we exit with status code 1.

I then found that the amount of vertical blank space in the result was
too damn high:

    myprompt$ ./src/cli/babeltrace2 query -p 'a=2,' ctf src.ctf.fs yo
    11-15 16:38:15.850 13799 13799 E CLI/CFG-CLI-ARGS bt_config_query_from_args@babeltrace2-cfg-cli-args.c:1530 Invalid format for --params option's argument:
        Expecting unquoted map key:

        a=2,
            ^

    11-15 16:38:15.851 13799 13799 E CLI main@babeltrace2.c:2781 Command-line error: retcode=1

    ERROR:    [Babeltrace CLI] (/home/smarchi/src/babeltrace/src/cli/babeltrace2.c:2781)
      Command-line error: retcode=1
    CAUSED BY [Babeltrace CLI] (/home/smarchi/src/babeltrace/src/cli/babeltrace2-cfg-cli-args.c:1530)
      Invalid format for --params option's argument:
          Expecting unquoted map key:

          a=2,
              ^

    myprompt$

So I removed the newlines added by ini_append_error_expecting.  I think
it looks readable and more concise this way.  Any caller who wants the
newlines can add them itself.

    myprompt$ ./src/cli/babeltrace2 query -p 'a=2,' ctf src.ctf.fs yo
    11-15 16:41:38.600 15717 15717 E CLI/CFG-CLI-ARGS bt_config_query_from_args@babeltrace2-cfg-cli-args.c:1530 Invalid format for --params option's argument:
        Expecting unquoted map key:

        a=2,
            ^
    11-15 16:41:38.600 15717 15717 E CLI main@babeltrace2.c:2781 Command-line error: retcode=1

    ERROR:    [Babeltrace CLI] (/home/smarchi/src/babeltrace/src/cli/babeltrace2.c:2781)
      Command-line error: retcode=1
    CAUSED BY [Babeltrace CLI] (/home/smarchi/src/babeltrace/src/cli/babeltrace2-cfg-cli-args.c:1530)
      Invalid format for --params option's argument:
          Expecting unquoted map key:

          a=2,
              ^
    myprompt$

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

tests: add missing backslash in tests/Makefile.am

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

tests: test_auto_source_discovery_grouping: remove dir_sep variable

It isn't used.  Fixes the following shellcheck diagnostics:

    In test_auto_source_discovery_grouping line 42:
            dir_sep='\'
                     ^-- SC1003: Want to escape a single quote? echo 'This is how it'\''s done'.

    In test_auto_source_discovery_grouping line 44:
            dir_sep='/'
            ^-----^ SC2034: dir_sep appears unused. Verify use (or export if used externally).

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

tests: silence "variable/expression in single quote" shellcheck warnings

shellcheck complains that we use a variable in single quotes:

    In test_trace_copy line 63:
                    uniq_ts_cnt="$("${BT_TESTS_AWK_BIN}" '{ print $1 }' < "${text_output1}" | sort | uniq | wc -l)"
                                                         ^------------^ SC2016: Expressions don't expand in single quotes, use double quotes for that.

In other cases, it's because of backticks (`) in a single quote string.

Silence these warnings locally by putting the appropriate comment:

    # shellcheck disable=SC2016

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

tests: quote ${BT_CTF_TRACES_PATH} in test_trace_read and test_trace_copy

Fixes these shellcheck errors:

    In test_trace_copy line 33:
    SUCCESS_TRACES=(${BT_CTF_TRACES_PATH}/succeed/*)
                    ^-------------------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.

    In test_trace_read line 29:
    SUCCESS_TRACES=(${BT_CTF_TRACES_PATH}/succeed/*)
                    ^-------------------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.

    In test_trace_read line 30:
    FAIL_TRACES=(${BT_CTF_TRACES_PATH}/fail/*)
                 ^-------------------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.

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

tests: declare and assign variables separately in test_exit_status

Fixes these shellcheck errors:

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

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

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

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

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

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

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

Make some bt_param_validation_map_value_entry_descr variables static

These variables are not used outside their respective files.

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

src.ctf.fs: make ctf_fs_ds_group_medops symbol hidden

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

ctf: make ctf scanner symbols hidden

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

param-validation: make symbols hidden

This convenience library is linked statically with the various plugins
that use it. The symbols are currently not marked as hidden, which
causes the plugins that use it (e.g. babeltrace-plugin-ctf.so) to expose
them publically. Sad.

Mark the symbols as hidden to avoid that.

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

python-plugin-provider: make python_state static

This variable is not used outside the file, it should not be exposed.

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

lib: add comments to exposed but internal symbols

These two functions, despite being exposed by the shared library, are
not part of the public ABI. They are only meant to be used by the
Python plugin provider, which is conceptually part of libbabeltrace2,
but implemented as a separate shared library. Add comments to explain
that.

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