2 years agoRelease: Babeltrace 2.0.0 "Amqui" v2.0.0
Jérémie Galarneau [Tue, 21 Jan 2020 22:02:59 +0000 (17:02 -0500)] 
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 <>
Change-Id: Id57d79cd0efba4aa0f8c699abe1def190dd841d7
Reviewed-by: Philippe Proulx <>
Reviewed-by: Michael Jeanson <>
2 years agocli: colorize version printing
Philippe Proulx [Tue, 21 Jan 2020 16:38:06 +0000 (11:38 -0500)] 
cli: colorize version printing

Signed-off-by: Philippe Proulx <>
Change-Id: I76388372a3b2f11ebb2ee76020f3d224f376f604
Reviewed-by: Francis Deslauriers <>
Tested-by: jenkins <>
2 years agocli: print full version name
Philippe Proulx [Tue, 21 Jan 2020 15:52:12 +0000 (10:52 -0500)] 
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 <>
Change-Id: I478da57eb24b6a8d0f9c7a0b7b1fb8a41d8e4867
Reviewed-by: Francis Deslauriers <>
Tested-by: jenkins <>
2 years agolib: add bt_version_get_extra_{name,description,patch_names}
Philippe Proulx [Tue, 21 Jan 2020 15:28:07 +0000 (10:28 -0500)] 
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 <>
Change-Id: I52abca8235826d1e336584285e925147895b13f4
Reviewed-by: Francis Deslauriers <>
Tested-by: jenkins <>
2 years agolib: add bt_version_get_vcs_revision_description()
Philippe Proulx [Tue, 21 Jan 2020 15:11:49 +0000 (10:11 -0500)] 
lib: add bt_version_get_vcs_revision_description()

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

Signed-off-by: Philippe Proulx <>
Change-Id: Iec5e5fb1bb220c3477bfecab3c3f35b103c0592e
Reviewed-by: Francis Deslauriers <>
Tested-by: jenkins <>
2 years agocommon: support custom, extra information for build's version
Philippe Proulx [Tue, 21 Jan 2020 14:55:43 +0000 (09:55 -0500)] 
common: support custom, extra information for build's version

This patch adds a system of extra version information also found in

`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

* 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 <>
Change-Id: Ife50e5bcaa6b3bdeda6ee4e7c1fdeb2fb1f63887
Reviewed-by: Francis Deslauriers <>
Reviewed-by: Michael Jeanson <>
Tested-by: jenkins <>
2 years, lib: rename "extra" (version) to "development stage"
Philippe Proulx [Tue, 21 Jan 2020 14:20:40 +0000 (09:20 -0500)], 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
where "Release candidate" is one of the stages.

Signed-off-by: Philippe Proulx <>
Change-Id: I285fbf9851cde41a520079b4c31cdc5d8bf32412
Reviewed-by: Francis Deslauriers <>
Tested-by: jenkins <>
2 years agolib: add bt_version_get_name() and bt_version_get_name_description()
Philippe Proulx [Mon, 20 Jan 2020 22:00:35 +0000 (17:00 -0500)] 
lib: add bt_version_get_name() and bt_version_get_name_description()

Signed-off-by: Philippe Proulx <>
Change-Id: If080c93994ac5869e29061b21d7b5c35387985d3
Reviewed-by: Francis Deslauriers <>
Tested-by: jenkins <>
2 years agolib: bt_version_get_extra(): return `NULL` if none instead of empty str.
Philippe Proulx [Mon, 20 Jan 2020 21:59:05 +0000 (16:59 -0500)] 
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 <>
Change-Id: I775f4f3be917bde405ad3b5e63183dae9609cf03
Reviewed-by: Francis Deslauriers <>
Tested-by: jenkins <>
2 years add version name/description definitions and report them
Philippe Proulx [Mon, 20 Jan 2020 21:54:03 +0000 (16:54 -0500)] add version name/description definitions and report them

Signed-off-by: Philippe Proulx <>
Change-Id: If287cce862facaaec71c63030ae578e24bcf4591
Reviewed-by: Francis Deslauriers <>
Reviewed-by: Michael Jeanson <>
Tested-by: jenkins <>
2 years agoDocument libbabeltrace2's C API
Philippe Proulx [Sat, 21 Sep 2019 16:02:25 +0000 (12:02 -0400)] 
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.


Signed-off-by: Philippe Proulx <>
Change-Id: I6d1dc2e7c5ee63fcd4220d0fd9f0931d361d2f31
Tested-by: jenkins <>
2 years agoFix: src.ctf.lttng-live: emitting stream end msg with no stream
Francis Deslauriers [Thu, 19 Dec 2019 21:39:45 +0000 (16:39 -0500)] 
Fix: src.ctf.lttng-live: emitting stream end msg with no stream

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

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:

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

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

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 <>
Change-Id: If7f52f43162e7263785713c01c226907fe475d94
CI-Build: Simon Marchi <>
Tested-by: jenkins <>
Reviewed-by: Simon Marchi <>
2 years agolib: msg. iter. inactivity message has a simple CS, not a default CS
Philippe Proulx [Tue, 14 Jan 2020 18:36:51 +0000 (13:36 -0500)] 
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 <>
Change-Id: I0142c4f91217791e3157d37a32f4e2f234afa8d2
Tested-by: jenkins <>
2 years agolib: remove self component param. from msg. iterator init. method
Philippe Proulx [Sat, 11 Jan 2020 13:57:43 +0000 (08:57 -0500)] 
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 <>
Change-Id: I81e967acfd99b6ef3a2e01ae2ee19008a3c60408
Tested-by: jenkins <>
Reviewed-by: Simon Marchi <>
2 years agolib: graph API: return borrowed references when adding to an object
Philippe Proulx [Sun, 12 Jan 2020 15:45:31 +0000 (10:45 -0500)] 
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 <>
Change-Id: I71a5e18760504d8f8610162e3f6d7bd8d87474f9
Tested-by: jenkins <>
Reviewed-by: Simon Marchi <>
2 years agolib: plugin-dev.h: rename `MESSAGE_ITERATOR` -> `MESSAGE_ITERATOR_CLASS`
Philippe Proulx [Fri, 10 Jan 2020 16:45:34 +0000 (11:45 -0500)] 
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 <>
Change-Id: Icbcefec886fcbb2b1928d4b1009f3aca88c032a0
CI-Build: Simon Marchi <>
Reviewed-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agolib: rename "self comp. input port message iter." -> "message iterator"
Philippe Proulx [Fri, 10 Jan 2020 02:16:39 +0000 (21:16 -0500)] 
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 <>
Change-Id: I219b25495911363595bdf3b8b3f3b3cf802f20ac
Reviewed-by: Simon Marchi <>
CI-Build: Simon Marchi <>
Tested-by: jenkins <>
2 years agolib: append `_FUNC` to `BT_PLUGIN_{INITIALIZE,FINALIZE}*`
Philippe Proulx [Fri, 10 Jan 2020 03:30:41 +0000 (22:30 -0500)] 

Signed-off-by: Philippe Proulx <>
Change-Id: Ie643815f2ec07149025d864324e6aefc55a14cd5
Tested-by: jenkins <>
Reviewed-by: Simon Marchi <>
2 years agoReplace `` with ``
Philippe Proulx [Wed, 8 Jan 2020 21:42:03 +0000 (16:42 -0500)] 
Replace `` with ``

Signed-off-by: Philippe Proulx <>
Change-Id: I87e6b0722358d74a0377b6b3f37ed81d65aeaa8c

2 years agolib: create common base for bt_component_class_{source,filter}
Simon Marchi [Tue, 7 Jan 2020 22:23:31 +0000 (17:23 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agolib: introduce bt_message_iterator_class
Simon Marchi [Fri, 20 Dec 2019 22:20:55 +0000 (17:20 -0500)] 
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

    src_cls = bt_component_class_source_create(my_iter_next_method);

would now become:

    iter_cls = bt_message_iterator_class_create(my_iter_next_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


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 <>
Tested-by: jenkins <>
2 years agolib: run most of bt_self_component_port_input_message_iterator_try_finalize when...
Simon Marchi [Wed, 11 Dec 2019 18:43:34 +0000 (13:43 -0500)] 
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
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

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

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 <>
Tested-by: jenkins <>
Reviewed-by: Francis Deslauriers <>
2 years agotests: plug memory leak in test_bin_info
Simon Marchi [Tue, 7 Jan 2020 19:51:41 +0000 (14:51 -0500)] 
tests: plug memory leak in test_bin_info

When running test_bin_info (e.g. through
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/
==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 <>
Tested-by: jenkins <>
Reviewed-by: Francis Deslauriers <>
2 years agodebug-info: free existing build-id in bin_info_set_build_id
Simon Marchi [Tue, 7 Jan 2020 19:42:34 +0000 (14:42 -0500)] 
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

Direct leak of 20 byte(s) in 1 object(s) allocated from:
    #0 0x7f623da26d38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/
    #1 0x7f623ce37b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/
    #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/

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 <>
Tested-by: jenkins <>
Reviewed-by: Francis Deslauriers <>
2 years agocli: free log level string value
Simon Marchi [Tue, 7 Jan 2020 19:23:47 +0000 (14:23 -0500)] 
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/
    #1 0x7f1e35d97b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/
    #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/

Reported-by: ASan
Change-Id: Ib2251d9dd8628bda128ae4d2e756d0d86fa12163
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agobt2: free port user data when finalizing components
Simon Marchi [Tue, 7 Jan 2020 01:47:20 +0000 (20:47 -0500)] 
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 * {
            $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 <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agobuild: try calling python-config with --embed
Simon Marchi [Sun, 29 Dec 2019 22:27:04 +0000 (17:27 -0500)] 
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:

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 <>
Reviewed-by: Michael Jeanson <>
2 years agotests: remove unnecessary message iterator classes
Simon Marchi [Tue, 7 Jan 2020 03:23:08 +0000 (22:23 -0500)] 
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 were simply unused, so I removed

Change-Id: I79f787b9d121a3dc6456f81090ebf51d088d2c73
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agotests: make test_sink_self_port_user_data actually test a sink
Simon Marchi [Tue, 7 Jan 2020 01:29:52 +0000 (20:29 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agolib: remove unnecessary (void *) cast in extend_map_element
Simon Marchi [Mon, 6 Jan 2020 19:00:31 +0000 (14:00 -0500)] 
lib: remove unnecessary (void *) cast in extend_map_element

Change-Id: I238aeef707d2822030c18e2a8dc1ebf4d432a9f2
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agocli: fix bt_plugin leak when using `-i ctf`
Simon Marchi [Mon, 6 Jan 2020 18:20:57 +0000 (13:20 -0500)] 
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/
       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 <>
Reported-by: Valgrind Memcheck
Tested-by: jenkins <>
2 years agocli: remove unused structures and enums
Simon Marchi [Mon, 6 Jan 2020 16:47:23 +0000 (11:47 -0500)] 
cli: remove unused structures and enums

These have apparently been unused for a while, since:

    commit db0f160afd671de44e52d2b364de957ddccdac02
    Author: Philippe Proulx <>
    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 <>
Tested-by: jenkins <>
2 years agotests: fix test failure with msys2's Python 3.8.1-1 package
Simon Marchi [Tue, 7 Jan 2020 03:33:49 +0000 (22:33 -0500)] 
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'))

When it should do this:

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

Because of this, tests/plugins/src.ctf.fs/query/
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:

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

Change-Id: Idcd865d87350682644a536ada95cfac161cc1182
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agotrimmer: free GMatchInfo object in set_bound_from_str
Simon Marchi [Tue, 31 Dec 2019 04:34:29 +0000 (23:34 -0500)] 
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/
    ==3711000==    by 0x49BCEAA: ??? (in /usr/lib/
    ==3711000==    by 0x49BD310: g_regex_match_full (in /usr/lib/
    ==3711000==    by 0x49BDEEA: g_regex_match (in /usr/lib/
    ==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 <>
Reviewed-by: Francis Deslauriers <>
2 years agobt2: rename `object` parameter -> `object_name`
Philippe Proulx [Wed, 18 Dec 2019 02:54:38 +0000 (21:54 -0500)] 
bt2: rename `object` parameter -> `object_name`

I think it's more evident this way.

Signed-off-by: Philippe Proulx <>
Change-Id: I20f80ab8b28c4f4f0d390dd9fb4676ff69e8e609
Tested-by: jenkins <>
2 years agolib: remove bt_query_executor_interrupt, add bt_query_executor_borrow_default_interrupter
Simon Marchi [Tue, 17 Dec 2019 19:11:36 +0000 (14:11 -0500)] 
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

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 <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agolib: remove bt_graph_interrupt, add bt_graph_borrow_default_interrupter
Simon Marchi [Mon, 16 Dec 2019 21:25:06 +0000 (16:25 -0500)] 
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

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

Change-Id: I277e6c8bb4e1be0a6557a6287b7ba8997e20d27b
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agolib: graph API: remove "listener removed" callback parameters
Philippe Proulx [Wed, 11 Dec 2019 21:50:21 +0000 (16:50 -0500)] 
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 <>
Change-Id: I4c06ff139740f887ae2ace7633d2edeb01fd2fa0
Tested-by: jenkins <>
2 years agolib, bt2: graph API: remove "ports connected" listeners
Philippe Proulx [Wed, 11 Dec 2019 20:48:32 +0000 (15:48 -0500)] 
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

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

Signed-off-by: Philippe Proulx <>
Change-Id: I218c7b7b57c52f2e8589b35e3d89f38dfd961c0a
Tested-by: jenkins <>
2 years agobabeltrace2-plugin-ctf(7): "theirs" -> "its" (single CTF trace)
Philippe Proulx [Thu, 12 Dec 2019 16:49:14 +0000 (11:49 -0500)] 
babeltrace2-plugin-ctf(7): "theirs" -> "its" (single CTF trace)

Signed-off-by: Philippe Proulx <>
Change-Id: I251e8c5c2a357637983be92abb597827ffadd7da

2 years ago.gitignore: add missing `/tests/lib/test_remove_..._destruction_listener`
Philippe Proulx [Wed, 11 Dec 2019 21:49:35 +0000 (16:49 -0500)] 
.gitignore: add missing `/tests/lib/test_remove_..._destruction_listener`

Signed-off-by: Philippe Proulx <>
Change-Id: I20a520668a9f2bff7c47891072f907fd2b53d9e6
Reviewed-by: Simon Marchi <>
2 years agoSync argpar with upstream
Simon Marchi [Fri, 6 Dec 2019 19:24:58 +0000 (14:24 -0500)] 
Sync argpar with upstream

Sync with commit:

    Add missing va_end in argpar_vasprintf

Change-Id: If005cbc043af96e4db9ad4d1a8b2d341944383d0
Signed-off-by: Simon Marchi <>

2 years agoUse argpar from upstream
Simon Marchi [Wed, 4 Dec 2019 23:07:44 +0000 (18:07 -0500)] 
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 <>

2 years agobt2: use format_bt_error and format_bt_error_cause to generate _Error and _ErrorCause...
Simon Marchi [Fri, 22 Nov 2019 13:31:24 +0000 (08:31 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agostring-format: introduce function to format a bt_error_cause
Simon Marchi [Tue, 26 Nov 2019 17:02:19 +0000 (12:02 -0500)] 
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

Change-Id: Ibf5b0363e9a239be6228580246b6613743ace09e
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agostring-format: introduce function to format a bt_error
Simon Marchi [Thu, 28 Nov 2019 16:30:03 +0000 (11:30 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agostring-format: introduce function to format component class name
Simon Marchi [Thu, 21 Nov 2019 21:58:12 +0000 (16:58 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agocommon: introduce struct bt_common_color_codes and function bt_common_color_get_codes
Simon Marchi [Fri, 22 Nov 2019 18:24:16 +0000 (13:24 -0500)] 
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:


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 <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agolib: standardize variant field option function names
Philippe Proulx [Tue, 3 Dec 2019 18:47:34 +0000 (13:47 -0500)] 
lib: standardize variant field option function names

This patch does the following changes:






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 <>
Change-Id: I7c8f19d06d86464b0b2131036c27adb8d909aaa3
Reviewed-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agobt2: don't print previous causes in causes created from bt2._Error
Simon Marchi [Mon, 2 Dec 2019 17:10:41 +0000 (12:10 -0500)] 
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 "", line 32, in <module>
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/", 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/", 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 "", line 26, in _user_consume
      File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/", 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/", 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/", line 201, in _bt_next_from_native
        msg = next(self)
      File "", 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/", line 201, in _bt_next_from_native
        msg = next(self)
      File "", 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 <>
Tested-by: jenkins <>
2 years agobt2: reverse order of printed causes in _Error.__str__
Simon Marchi [Mon, 2 Dec 2019 16:35:11 +0000 (11:35 -0500)] 
bt2: reverse order of printed causes in _Error.__str__

To match how the CLI prints them.

Change-Id: Ief913b119b169bf9f620531f8763db93e19bda27
CI-Build: Simon Marchi <>
Tested-by: jenkins <>
Reviewed-by: Simon Marchi <>
2 years agobt2: remove ptr parameter of _Error.__init__
Simon Marchi [Mon, 2 Dec 2019 16:25:30 +0000 (11:25 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agotests: add test for list-plugins CLI command
Simon Marchi [Wed, 20 Nov 2019 17:01:18 +0000 (12:01 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agotests: test removing a destruction listener from a destruction listener
Simon Marchi [Wed, 20 Nov 2019 23:51:28 +0000 (18:51 -0500)] 
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

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 <>
Tested-by: jenkins <>
2 years agotests/lib/ Move libbabeltrace2-common and libbabeltrace2-logging to COMMO...
Simon Marchi [Wed, 20 Nov 2019 23:11:35 +0000 (18:11 -0500)] 
tests/lib/ 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 <>
Tested-by: jenkins <>
2 years agobt2: make _ListenerHandle not hold a strong reference on the target object
Simon Marchi [Wed, 20 Nov 2019 20:25:06 +0000 (15:25 -0500)] 
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 /

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 <>
Reviewed-by: Philippe Proulx <>
2 years agobt2: fix error message in
Simon Marchi [Wed, 20 Nov 2019 22:55:49 +0000 (17:55 -0500)] 
bt2: fix error message in

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

Change-Id: Ib9fcae27102a90ffe5492e74906ca1a1d5205dfc
Signed-off-by: Simon Marchi <>

2 years agobt2: make Graph add listener methods return None
Simon Marchi [Wed, 20 Nov 2019 20:29:42 +0000 (15:29 -0500)] 
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

Change-Id: I5ea1c9d8793232c2f7077b5c2b82797438066d13
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agoparam-parse: allow duplicate map keys
Simon Marchi [Wed, 20 Nov 2019 21:22:49 +0000 (16:22 -0500)] 
param-parse: allow duplicate map keys

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

  -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

Change-Id: Id39e86bb48ac52c6714db3128b7d767f5347de64
Signed-off-by: Simon Marchi <>

2 years agobt2: validate parameters to _StreamClass.create_event_class before creating the nativ...
Simon Marchi [Tue, 19 Nov 2019 22:44:12 +0000 (17:44 -0500)] 
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 <>

2 years agobt2: add invalid parameter type test for _UserComponent._create_trace_class
Simon Marchi [Tue, 19 Nov 2019 22:20:54 +0000 (17:20 -0500)] 
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 <>

2 years agosrc.ctf.fs: sort inputs paths
Simon Marchi [Fri, 15 Nov 2019 22:20:49 +0000 (17:20 -0500)] 
src.ctf.fs: sort inputs paths

Sort input paths to make the behavior of the component more

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

2 years agocli: print error causes in all error paths
Simon Marchi [Fri, 15 Nov 2019 21:17:46 +0000 (16:17 -0500)] 
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

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


    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:


    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:



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:

    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:


Change-Id: Id38159896d595b9c8fcac00b3364577e1ea36883
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agotests: add missing backslash in tests/
Simon Marchi [Wed, 20 Nov 2019 17:04:24 +0000 (12:04 -0500)] 
tests: add missing backslash in tests/

Change-Id: I676829a841ad09e6e2df9894272f6c85a9cff1ca
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agotests: test_auto_source_discovery_grouping: remove dir_sep variable
Simon Marchi [Wed, 20 Nov 2019 16:24:47 +0000 (11:24 -0500)] 
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:
                     ^-- SC1003: Want to escape a single quote? echo 'This is how it'\''s done'.

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

Reported-by: shellcheck
Change-Id: I9db00870cd697d5ad3bd5aa362a030a4b75f4e4c
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agotests: silence "variable/expression in single quote" shellcheck warnings
Simon Marchi [Wed, 20 Nov 2019 16:20:29 +0000 (11:20 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agotests: quote ${BT_CTF_TRACES_PATH} in test_trace_read and test_trace_copy
Simon Marchi [Wed, 20 Nov 2019 16:15:30 +0000 (11:15 -0500)] 
tests: quote ${BT_CTF_TRACES_PATH} in test_trace_read and test_trace_copy

Fixes these shellcheck errors:

    In test_trace_copy line 33:
                    ^-------------------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.

    In test_trace_read line 29:
                    ^-------------------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.

    In test_trace_read line 30:
                 ^-------------------^ 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 <>
Tested-by: jenkins <>
2 years agotests: declare and assign variables separately in test_exit_status
Simon Marchi [Wed, 20 Nov 2019 16:12:45 +0000 (11:12 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agoMake some bt_param_validation_map_value_entry_descr variables static
Simon Marchi [Tue, 19 Nov 2019 18:51:10 +0000 (13:51 -0500)] 
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 <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agosrc.ctf.fs: make ctf_fs_ds_group_medops symbol hidden
Simon Marchi [Tue, 19 Nov 2019 18:48:03 +0000 (13:48 -0500)] 
src.ctf.fs: make ctf_fs_ds_group_medops symbol hidden

Change-Id: I96c7f3aaf76c94337cd0efb1eb71b9cf76a1e5fa
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agoctf: make ctf scanner symbols hidden
Simon Marchi [Tue, 19 Nov 2019 18:47:52 +0000 (13:47 -0500)] 
ctf: make ctf scanner symbols hidden

Change-Id: I21d2e25fe96d308ae949d2e3ac090e05cabbefaf
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agoparam-validation: make symbols hidden
Simon Marchi [Tue, 19 Nov 2019 17:26:36 +0000 (12:26 -0500)] 
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. to expose
them publically.  Sad.

Mark the symbols as hidden to avoid that.

Change-Id: If099b529f7c126f5defd5242486009c3fd4195eb
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agopython-plugin-provider: make python_state static
Simon Marchi [Tue, 19 Nov 2019 17:24:04 +0000 (12:24 -0500)] 
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 <>
Tested-by: jenkins <>
2 years agolib: add comments to exposed but internal symbols
Simon Marchi [Tue, 19 Nov 2019 17:07:22 +0000 (12:07 -0500)] 
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

Change-Id: I704240070403c9dd5d75f15e107c00b011d8a5ef
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agolib: add comment to bt_plugin_so_create_all_from_static
Simon Marchi [Tue, 19 Nov 2019 17:05:24 +0000 (12:05 -0500)] 
lib: add comment to bt_plugin_so_create_all_from_static

This symbol would normally not be exposed, but it is used from the
Python plugin provider, which is conceptually part of libbabeltrace2,
but implemented as a separate shared library.  Add a comment to explain

Change-Id: Ie6e14edc30489ab6f8c6aadba32a3ceb9726e3b0
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agolib: make bt_object_pool symbols hidden
Simon Marchi [Tue, 19 Nov 2019 17:04:25 +0000 (12:04 -0500)] 
lib: make bt_object_pool symbols hidden

bt_object_pool_initialize and bt_object_pool_finalize are not supposed
to be exposed by the shared library, so make them hidden.

Change-Id: I072b692f627f4b66b4e5907eeb228d6327d3d70e
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agolib: make symbols in prio-head hidden
Simon Marchi [Tue, 19 Nov 2019 17:01:30 +0000 (12:01 -0500)] 
lib: make symbols in prio-head hidden

These are not supposed to be exposed by the shared library, so make them

Change-Id: If1f728f1b536d1be1e38dfff8ca2aba8d4bd1868
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
2 years agotests: add CLI query tests
Simon Marchi [Tue, 22 Oct 2019 21:55:25 +0000 (17:55 -0400)] 
tests: add CLI query tests

Add a few simple tests for the query CLI command, using a custom Python
component class.

Change-Id: Ic2b2d3f9f5e0f460f596bd1e4403c250ec2daad5
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agoparam-parse: use g_string_append_c instead of g_string_append_printf
Simon Marchi [Tue, 19 Nov 2019 16:22:42 +0000 (11:22 -0500)] 
param-parse: use g_string_append_c instead of g_string_append_printf

... to append a single character.

I did some tests to evaluate the performance impact of this patch, in
terms of number of instructions.  I ran the following command line 20
times and computed the average and standard deviation of the number of
execution instructions.

    $ libtool --mode=execute perf stat -e instructions:u ./src/cli/babeltrace2 query -p 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=2,' src.ctf.fs yo

                     average     stdev
Without this patch:  1079692     51
With this patch:     1039197     51

This represents a reduction of 3.75% in the number of executed

Change-Id: I8109d42d0fa357e47642132a2f3b9581d72bcefa
Signed-off-by: Simon Marchi <>
Reviewed-by: Philippe Proulx <>
Tested-by: jenkins <>
2 years agolib: remove bt_packet_context_field API
Simon Marchi [Wed, 13 Nov 2019 22:00:08 +0000 (17:00 -0500)] 
lib: remove bt_packet_context_field API

Change-Id: I357daa5915140882dab47acb70570178fb767db8
Signed-off-by: Simon Marchi <>
Reviewed-by: Philippe Proulx <>
2 years agoctf: make msg-iter not use bt_packet_context_field
Simon Marchi [Fri, 15 Nov 2019 19:39:59 +0000 (14:39 -0500)] 
ctf: make msg-iter not use bt_packet_context_field

The bt_packet_context_field API exists so that the CTF message iterator
could store packet context fields in contexts where it doesn't create
trace-ir objects.  For example, in add_ds_file_to_ds_file_group, we use
a message iterator just to sniff the properties of the first packet of a
data stream file.

However, the CTF message iterator doesn't really use it anymore, it just
stores the relevant properties in fields of the ctf_msg_iter structure
and transfers them to the caller in ctf_msg_iter_get_packet_properties.

So the bt_packet_context_field API no longer has a reason to be.  This
patch makes msg-iter stop using it, so it can be removed.

Currently, the packet_context_field is created when needed, which is
just before reading the packet context, in
read_packet_context_begin_state.  A bt_packet is later created in
create_msg_packet_beginning, and the packet_context_field is moved into
the bt_packet.

If we want to get rid of the packet_context_field, it means we need to
create the bt_packet earlier (if not in dry_run mode), so it is
available in read_packet_context_begin_state, so that the packet context
fields are read directly into the bt_packet.  And to create the
bt_packet, the bt_stream needs to be available.  The bt_stream is
currently created just before sending the stream beginning message, in

So this patch moves the creation of the bt_stream and bt_packet as early
as possible, just after we have read the packet header, in
after_packet_header_state.  In read_packet_context_begin_state, we can
then find the packet already created in msg_iter->packet.

This change made it necessary to set the dry run flag on the CTF message
iterator in add_ds_file_to_ds_file_group (which should have probably
already been there anyway).  This iterator is used to read the packet
context, which, previously, didn't trigger the creation of the bt_stream
and bt_packet.  But now that we create those earlier, it is necessary
to set the flag to avoid them being created.

It was also needed to change the check in after_packet_context_state to
know whether we are at the first packet, and therefore need to emit a
stream beginning message, or if we are at a subsequent packet, and
therefore need to skip that step.  We would previously check whether the
msg_it->stream field was set, but this is now always true given that we
set the stream earlier.  The only way that I found to fix that is to add
the boolean flag emit_stream_beginning_message in the message iterator.

Change-Id: Ib907480727d00d51aabd89986375d533ad385c96
Signed-off-by: Simon Marchi <>
Reviewed-by: Philippe Proulx <>
2 years agoctf: remove ctf_msg_iter::set_stream
Simon Marchi [Mon, 18 Nov 2019 19:37:33 +0000 (14:37 -0500)] 
ctf: remove ctf_msg_iter::set_stream

This field is set but not used.

Change-Id: Ibca38c8421b8d734462077a19da1726a817f3cb6
Signed-off-by: Simon Marchi <>
Reviewed-by: Philippe Proulx <>
2 years agosrc.ctf.fs: fix typo in comment
Simon Marchi [Tue, 19 Nov 2019 21:11:44 +0000 (16:11 -0500)] 
src.ctf.fs: fix typo in comment

Change-Id: I2a3ee8d019b7dfb966aba3a1e9a5d7fc375eb9e7
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
Reviewed-by: Francis Deslauriers <>
2 years agolib: mark bt_common_assert_failed as hidden
Simon Marchi [Mon, 18 Nov 2019 21:45:46 +0000 (16:45 -0500)] 
lib: mark bt_common_assert_failed as hidden

I noticed that the bt_common_assert_failed symbol was exported.  This is
not desirable, as it's not part of the API, so mark it with BT_HIDDEN.

As a consequence, a bunch of small tests that use BT_ASSERT miss this
symbol, as they were getting it from libbabeltrace2.  Make them depend
on libbabeltrace2-common (and libbabeltrace2-logging) directly to fix

Change-Id: I25ab69e7df08f508389f5c9c3db5571ee7b06d7b
Signed-off-by: Simon Marchi <>
Tested-by: jenkins <>
Reviewed-by: Philippe Proulx <>
2 years agoUpdate version to v2.0.0-rc4 v2.0.0-rc4
Jérémie Galarneau [Fri, 15 Nov 2019 22:39:12 +0000 (17:39 -0500)] 
Update version to v2.0.0-rc4

Signed-off-by: Jérémie Galarneau <>
Change-Id: Ia3ada317153a283c90841b273c78cac3bc032655

2 years agoUpdate version to v2.0.0-rc3
Jérémie Galarneau [Fri, 15 Nov 2019 22:21:22 +0000 (17:21 -0500)] 
Update version to v2.0.0-rc3

Signed-off-by: Jérémie Galarneau <>
Change-Id: Ic5194bd526c8eb7456e3e58c89c899ba07d9e4c9

2 years agobabeltrace2-source.ctf.fs(7): document the overlapping snapshot feature
Philippe Proulx [Fri, 15 Nov 2019 22:09:05 +0000 (17:09 -0500)] 
babeltrace2-source.ctf.fs(7): document the overlapping snapshot feature

Signed-off-by: Philippe Proulx <>
Change-Id: I482a366679f65a577cb7081ce46736ab484858c3

2 years agoRevert "Notes de relâche du troisième candidat de relâche"
Simon Marchi [Fri, 15 Nov 2019 18:28:02 +0000 (13:28 -0500)] 
Revert "Notes de relâche du troisième candidat de relâche"

This reverts commit 98403f26955dc80727dc34974ba1e98d0ead61d1.

2 years agoNotes de relâche du troisième candidat de relâche
Simon Marchi [Thu, 14 Nov 2019 22:27:14 +0000 (17:27 -0500)] 
Notes de relâche du troisième candidat de relâche

Change-Id: I8d3811ed4fc3196434ee2aebc1af6c542df53824

2 years agoctf: remove ctf_msg_iter_set_emit_stream_{beginning,end}_message functions
Simon Marchi [Tue, 12 Nov 2019 20:26:42 +0000 (15:26 -0500)] 
ctf: remove ctf_msg_iter_set_emit_stream_{beginning,end}_message functions

These functions are now unnecessary.  Before the previous patch
"src.ctf.fs: add and use medops to iterate on a ds_file_group using the
index", the src.ctf.fs component used ctf_msg_iter in such a way that
the iterator would process complete data stream files one after the
other, and was reset between each file.  When starting a data stream
file, the iterator needed to know whether it was the first data stream
file for a given stream, and therefore if it should emit the stream
beginning message.  Conversely, it needed to know if the data stream
file was the last one for the stream, and therefore if it needed to emit
the stream end message.

With the new ctf_fs_ds_group_medops, the ctf_msg_iter reads entire
streams, even if they are spread over multiple data stream files.  We
therefore don't need to say whether a particular iterator run is the
beginning or end of a stream, it always is.

With lttng-live, the iterator also always does a single run so always
needs to emit the stream messages.

This patch also removes the related fields in ctf_msg_iter, as well as
the related states in the state machine.

The only non-obvious thing is: what to do with the call to
set_current_stream in check_emit_msg_stream_beginning_state.  This is
the moment where the message iterator asks the medium to provide the
bt_stream instance for the given stream class and stream instance id.
For now, I moved it to just before we need it the first time, which is
when sending the stream beginning message.  This is probably temporary
anyway, as it is planned that we will be able to just pass the bt_stream
when creating the ctf_msg_iter.

Change-Id: I275d4631ff11612abb46c73312bf133753ae4971
Signed-off-by: Simon Marchi <>
2 years agosrc.ctf.fs: use ctf_fs_ds_index_destroy to free index
Simon Marchi [Thu, 14 Nov 2019 21:32:34 +0000 (16:32 -0500)] 
src.ctf.fs: use ctf_fs_ds_index_destroy to free index

The function ctf_fs_ds_file_group_destroy frees the ctf_fs_ds_index
structure and its content by hand.  Replace that with a call to
ctf_fs_ds_index_destroy, which is meant for that.

Change-Id: I186b1da9ec63cbdfa7ef7966d1e0e9802827e4f7
Signed-off-by: Simon Marchi <>
2 years agosrc.ctf.fs: add and use medops to iterate on a ds_file_group using the index
Simon Marchi [Wed, 6 Nov 2019 21:01:24 +0000 (16:01 -0500)] 
src.ctf.fs: add and use medops to iterate on a ds_file_group using the index

This patch solves the problem of reading multiple snapshots of the same
tracing session taken quickly.  Taking the snapshots quickly enough can
cause them to overlap, in which case some complete / identical packets
will be found in different snapshots.

As an example, imagine we have three snapshots, and packets labeled from
A to G belonging the same stream instance in all snapshots.  We could
have the following sequence of packets in each snapshot:

  - snapshot 1: A B C D
  - snapshot 2:     C D E F
  - snapshot 3:       D E F G

Babeltrace 1 reads these three snapshots successfully.  In fact, it just
considers them as three different traces, so it will order events
individually.  As a result, events from packet D will be present three
times in the output.  So while it works (as in Babeltrace exits with
status 0), it's probably not what a user would want.

Babeltrace 2 (before this patch) hits the following assert, which
validates that messages produced by iterators never go back in time:

    11-11 15:13:23.874  8329  8329 F LIB/MSG-ITER call_iterator_next_method@iterator.c:872 Babeltrace 2 library postcondition not satisfied; error is:
    11-11 15:13:23.874  8329  8329 F LIB/MSG-ITER call_iterator_next_method@iterator.c:872 Clock snapshots are not monotonic
    11-11 15:13:23.874  8329  8329 F LIB/MSG-ITER call_iterator_next_method@iterator.c:872 Aborting...

This is because Babeltrace 2 groups all CTF traces sharing the same UUID
(which is the case for our three snapshots) and gives them to the same
src.ctf.fs component to read.  The component groups data stream files
from the various snapshots by stream instance id, and sorts them
according to the timestamp of their first event.  It then reads them
sequentially, from end to end, assuming that the start of the second
data stream file is after the end of the first data stream file.  Using
our example above, the src.ctf.fs component would therefore try to read
packets in this order:

    A B C D C D E F D E F G
   `- ouch!

In this case, we want to read all packets exactly once, in the right

The solution brought by this patch is to iterate on the packets by
following the index, instead of reading all data files from end to end.
Index entries were already de-duplicated by commit

    ctf: de-duplicate index entries

So the index already refers to a single instance of each packet.  We can
therefore use it as a playlist of the packets to read.

The change mainly revolves around adding a new kind of CTF message
iterator medium operations, called ctf_fs_ds_group_medops.  Instead of
the medium being a single data stream file, like in
ctf_fs_ds_file_medops, this new medium is conceptually the sequence of
all packets described by the index of a ctf_fs_ds_group, possibly spread
out in different data stream files.

A new optional medium operation called `switch_packet` is added.  When
the CTF message iterator is done reading a packet, it calls this method,
indicating to the medium that it is at the frontier of two packets.  If
the medium is aware of the packets (like ctf_fs_ds_group_medops is) and
knows that the following packet is not contiguous with the previous
packet, it can reposition its "read head" at the right place (open the
new file, go to the right offset).  Immediatly after calling
`switch_packet`, the message iterator calls the `request_bytes` method,
which allows the medium to return a buffer containing the bytes of the
next packet.

When the packet-aware medium has its `switch_packet` method called but
there are no more packets to read, it returns
CTF_MSG_ITER_MEDIUM_STATUS_EOF.  That brings the message iterator in the
STATE_CHECK_EMIT_MSG_STREAM_END state, which will close the stream.

If the `switch_packet` method is not provided by the medium, the message
iterator just continues, assuming that the bytes of the next packet are
contiguous with those of the previous packet.

The ctf_fs_ds_file_medops medium operations are still necessary for
reading individual ctf_fs_ds_files, when initializing src.ctf.fs
components.  This is needed when building the index from a stream or for
applying tracer fixups.

This simplifies a little bit the interaction between the src.ctf.fs
iterator and the ctf_msg_iter.  Previously, we would read each data
stream file until the message iterator returned EOF.  If it wasn't the
last data stream file, we would reset the iterator to read the next data
stream file.  Functions
ctf_msg_iter_set_emit_stream_{beginning,end}_message were necessary to
indicate to the message iterator whether to send the stream beginning or
end messages, because it had otherwise no idea of whether the data
stream file it is reading is the first one or last one.  The function
ctf_msg_iter_set_medops_data was necessary to swap the data of the
ctf_fs_ds_file_medops to point to the new data stream file.

With the ctf_fs_ds_group_medops, the CTF message iterator only returns
EOF when the stream is done.  The data passed to the
ctf_fs_ds_group_medops has everything it needs to go through all the
packets, so it doesn't need to change.

Change-Id: I72f6d1e09b87414fb83f68cb57abb1f2dc61b439
Signed-off-by: Simon Marchi <>
2 years agotests: make test_trimmer use bt_cli
Simon Marchi [Mon, 11 Nov 2019 21:55:42 +0000 (16:55 -0500)] 
tests: make test_trimmer use bt_cli

... instead of launching babeltrace2.exe by hand.  This makes the
testsuite print the executed command lines, and is therefore easier to

Change-Id: I82f3984e749b8e6aff38b529ed462373eabd24dc
Signed-off-by: Simon Marchi <>
2 years agosrc.ctf.fs: factor out "ds_file_mmap" from "ds_file_mmap_next"
Simon Marchi [Tue, 5 Nov 2019 22:05:50 +0000 (17:05 -0500)] 
src.ctf.fs: factor out "ds_file_mmap" from "ds_file_mmap_next"

Currently, the logic to mmap a region of a ds_file is contained in
ds_file_mmap_next.  ds_file_mmap_next is also responsible for mapping
the region immediately following the currently mapped region, if there
is a currently mapped region.

I find this double responsibility a bit confusing, especially where
ds_file_mmap_next is used in medop_seek.

This patch extracts a portion of ds_file_mmap_next to a new function
ds_file_mmap, whose job is to ensure a file offset is mapped, and to do
the needful if it isn't.

Change-Id: Ia19725d28cf9c24084a52d16c7a88f30b32ff694
Signed-off-by: Simon Marchi <>
2 years agosrc.ctf.fs: remove ctf_fs_ds_file::end_reached field
Simon Marchi [Tue, 5 Nov 2019 22:44:59 +0000 (17:44 -0500)] 
src.ctf.fs: remove ctf_fs_ds_file::end_reached field

It is set, but not used for anything, so remove it.

Change-Id: I502fa683e6ab94a54959918978c4ffd683c5768e
Signed-off-by: Simon Marchi <>
2 years agoctf: assert that request_sz in medium ops request_bytes is greater than 0
Simon Marchi [Tue, 5 Nov 2019 22:21:47 +0000 (17:21 -0500)] 
ctf: assert that request_sz in medium ops request_bytes is greater than 0

There's a check in medop_request_bytes to return OK if the passed
request_sz is 0.  I don't think that can ever happen, since that
request_sz comes from the max_request_sz parameter when the iterator is
created.  It wouldn't make sense to pass 0.

Change-Id: Ia2c8fb6e56195bcab607c39e366c6b58b3411f8b
Signed-off-by: Simon Marchi <>
2 years agoctf: make ctf_msg_iter_seek assert that the seek callback is not NULL
Simon Marchi [Tue, 5 Nov 2019 21:00:57 +0000 (16:00 -0500)] 
ctf: make ctf_msg_iter_seek assert that the seek callback is not NULL

There should be no reason to call ctf_msg_iter_seek if there is no seek
callback.  It's the user of the ctf_msg_iter who passes medium
operations (at creation time), so it should be aware if there is a seek
callback or not.

This allows removing the UNSUPPORTED values in enum ctf_msg_iter_status
and enum ctf_msg_iter_medium_status.

Change-Id: Ic3591b1e909c7cf0e12d18f40b921a180cf344c8
Signed-off-by: Simon Marchi <>
2 years agoctf: assert that msg iter and medium seek offset is valid
Simon Marchi [Tue, 5 Nov 2019 20:22:39 +0000 (15:22 -0500)] 
ctf: assert that msg iter and medium seek offset is valid

I don't think there is ever a valid situation for `offset` to have an
invalid value in ctf_msg_iter_seek or medop_seek.  If the user of the
iterator (e.g.  fs.c) thinks it's cool enough to seek, it should know
about the underlying medium it used to create the msg iter and make sure
not to seek at an invalid position.

This allows removing the INVAL values in enum ctf_msg_iter_medium_status
and enum ctf_msg_iter_status.

Change-Id: I19d48fe751aebf21e60c5cbc16127919a5fa72f3
Signed-off-by: Simon Marchi <>
2 years agosrc.ctf.fs: remove ctf_msg_iter_seek_whence parameter to medium ops seek
Simon Marchi [Tue, 5 Nov 2019 20:18:01 +0000 (15:18 -0500)] 
src.ctf.fs: remove ctf_msg_iter_seek_whence parameter to medium ops seek

It is useless, as there is a single value.  If we ever really need to
specify if the given offset is absolute or relative, we can add back a
parameter, as this is an internal API.  In the mean time, it's just an

Change-Id: I3eba79f51d9d5aee82d3bed6ce736459f8dbffa3
Signed-off-by: Simon Marchi <>
2 years agosrc.ctf.fs: little status code cleanup
Simon Marchi [Tue, 5 Nov 2019 20:13:20 +0000 (15:13 -0500)] 
src.ctf.fs: little status code cleanup

Make ds_file_munmap return an enum ctf_msg_iter_medium_status, so it
integrates well with the rest.  Adjust error handling around the call
sites to be more consistent.

Change-Id: Iea299c782dc215fc64cc3068e58e334f2acb85de
Signed-off-by: Simon Marchi <>
This page took 0.085956 seconds and 4 git commands to generate.