Last commit made on 2020-04-23
Get this branch:
git clone -b master

Branch merges

Branch information


Recent commits

d8a3c3b... by Simon Marchi <email address hidden> on 2020-04-22

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


  babeltrace2 --debug /some/trace

... results in the following crash:

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

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

Change-Id: Ie3985d8b7c4e02ac7d09aee84bfe46ea4bab87e9
Signed-off-by: Simon Marchi <email address hidden>
Reviewed-by: Geneviève Bastien <email address hidden>
Reviewed-by: Philippe Proulx <email address hidden>

2831529... by .eepp on 2020-04-22

Fix: lib: BT_ASSERT_PRE_NON_NULL_FROM_FUNC(): change `: ` -> `.` in msg.

This changes, for example,

    Error is:
    Value object is NULL:


    Error is:
    Value object is NULL.

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: Ic122d50f5cb88dd72978d5dd8e2e4b22ee965a3e
Reviewed-by: Simon Marchi <email address hidden>
Tested-by: jenkins <email address hidden>

5d7e835... by .eepp on 2020-04-14

tests: add libbabeltrace2 pre/postcondition testing infrastructure

This patch adds a basic libbabeltrace2 pre/postcondition testing
infrastructure to the project.

When a libbabeltrace2 public function precondition or postcondition is
not satisfied, the function logs a FATAL-level message which indicates
what's wrong and then aborts. Slow path functions check such conditions
unconditionally, while fast path functions check them only in developer

Testing that a libbabeltrace2 function catches an unsatisfied
pre/postcondition and reports it is not straightforward: the library
aborts the program, so we can't use the usual approach because the test
program itself would abort.

The solution brought by this patch is the following process in

1. The `conds-triggers.c` program contains all the pre/postcondition
   failure triggering instructions to test, one condition per function.

   Each triggering function triggers a single pre/postcondition check.
   It is expected that the function actually aborts.

   main() calls ppc_main(), an internal utility, with its command-line
   arguments and an array of condition trigger descriptors.

   Each condition trigger descriptor has:

   * A condition type: precondition or postcondition.
   * The ID of the condition to trigger.
   * A name suffix.
   * A condition triggering function.

   Each condition trigger descriptor has a unique name: its condition ID
   and an optional name suffix.

   As of this patch, the PPC_TRIGGER_*_RUN_IN_COMP_CLS_INIT() macros
   create condition trigger descriptors of which the function runs
   within a component class initialization function (accepts a
   `bt_self_component *` parameter). This is often needed as many
   libbabeltrace2 functions are only accessible through a self component
   (all the trace IR API, for example).

   ppc_main() handles two command-line subcommands:

       Prints a JSON array of objects which represent the triggering
       descriptors, for example (output for this patch):

               "cond-id": "pre:field-class-integer-set-field-value-range:valid-n",
               "name": "pre:field-class-integer-set-field-value-range:valid-n-0"
               "cond-id": "pre:field-class-integer-set-field-value-range:valid-n",
               "name": "pre:field-class-integer-set-field-value-range:valid-n-gt-64"
               "cond-id": "pre:field-class-integer-set-field-value-range:not-null:field-class",
               "name": "pre:field-class-integer-set-field-value-range:not-null:field-class"

   `run INDEX`:
       Runs the condition triggering function for the descriptor at
       index `INDEX` in the `list` array.

       It is expected that this command aborts.

2. `test_conds` is a Bash script which only does this:

       export BT_TESTS_LIB_CONDS_TRIGGER_BIN="$BT_TESTS_BUILDDIR/$reldir/conds-triggers"

       if [ "$BT_OS_TYPE" = "mingw" ]; then

       run_python_bt2_test "$BT_TESTS_SRCDIR/$reldir"

   In other words, it runs the Python TAP test runner to discover and
   run tests in ``.

   This script is part of the `make check` test set.

3. In ``, a function:

   a) Runs `conds-triggers list` and decodes the output to get the list
      of available condition trigger descriptors.

      This step also validates the regular expressions and checks that
      there are no duplicate descriptor names.

   b) For each condition trigger descriptor, creates and adds a test to
      its single test case class which:

        I. Executes `conds-triggers run INDEX` as a subprocess,
           where `INDEX` is the descriptor's index.

       II. Reads the complete process's standard error.

      III. Asserts that the process aborts (`SIGABRT` signal).

           This seems to be only possible on a POSIX system with the
           `subprocess.Popen` API.

       IV. Asserts that the standard error (II) contains the
           descriptor's condition ID.

All this is only enabled if, at configuration time:

* Python 3 is available.
* The Babeltrace 2 developer mode is enabled (`BABELTRACE_DEV_MODE=1`).

This patch's `conds-triggers.c` includes two precondition triggering
functions to confirm that everything works as expected:

    When calling bt_field_class_integer_set_field_value_range(), the
    parameter `N` cannot be greater than 64.

    When calling bt_field_class_integer_set_field_value_range(), the
    parameter `N` cannot be 0.

    When calling bt_field_class_integer_set_field_value_range(), the
    field class cannot be `NULL`.

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I70713d690f7dbfeac5804e6cfcec989242823611

1778c2a... by .eepp on 2020-04-21

lib: assign a unique ID to each pre/postcond. and report it on failure

This patch changes the libbabeltrace2 pre/postcondition assertion macros
so that each precondition and postcondion has a unique ID within the

The macros report (log with a FATAL level) the condition ID on assertion
failure as such (logging prefixes removed):

    Babeltrace 2 library precondition not satisfied.
    Condition ID: `pre:field-class-integer-set-field-value-range:valid-n`.
    Function: bt_field_class_integer_set_field_value_range().
    Error is:
    Unsupported size for integer field class's field value range
    (minimum is 1, maximum is 64): size=65

The main goal of this change is to make it easier to test library
precondition and postcondition assertions: now you only need to confirm
that the log indicates the expected condition ID, making the details
("Unsupported size for [...]" in the example above) unimportant.

The condition IDs could also exist in the documentation so as to make it
easier to search for libbabeltrace2 pre/postcondition documentation when
failing to satisfy one.

The general condition ID format is:



    `pre` or `post`.

    Name of the API function (precondition) or user function type
    (postcondition) without the `bt_` prefix and with `_` replaced with

    With the scope of the function: unique, specific precondition or
    postcondition ID.

The BT_ASSERT_PRE_FROM_FUNC() macro (and its developer mode counterpart)
accepts a function name and an ID suffix.

The BT_ASSERT_PRE() macro (and its developer mode counterpart) only
accepts an ID suffix: it uses BT_ASSERT_PRE_FROM_FUNC() with `__func__`
as the function name.

All the other precondition assertion macros follow the same scheme:
`_FROM_FUNC` suffix for a specific function, no suffix for the current

Many precondition assertion macros in `assert-cond.h` build a complete
ID suffix based on a part of it. For example, BT_ASSERT_PRE_NON_NULL()
accepts an object ID, so that

    BT_ASSERT_PRE_NON_NULL("description", descr, "Description");

has the condition ID, when used from the hypothetical public function
bt_do_xyz(), `pre:do-xyz:not-null:description`.

It is imperative that the used API function name is always the one the
user called. Knowing this, internal, static functions _cannot_ use
BT_ASSERT_PRE() because the reported function name would be the internal
one. Not only is this confusing for the library user, it could also
change in the future.

This patch uses two strategies to deal with this constraint depending
on the intended execution path of the public function:

Slow path:
    The common (internal) function accepts an `api_func` parameter which
    is the ultimate public API function name.

    The common function only uses precondition assertion macros which
    end with `_FROM_FUNC`.

    A public function which calls this common function passes `__func__`
    as its `api_func` parameter.

Fast path:
    We define (locally) a new macro which uses the required precondition
    assertion macros (the variants without `_FROM_FUNC`).

    A public function which calls the common function uses the custom

Postconditions are checked when a user function returns. Therefore, the
function name in that case is the user function type name.
BT_ASSERT_POST() accepts a function name and an ID suffix.

_BT_ASSERT_COND() calls the internal bt_lib_assert_cond_failed() which
formats the condition ID, prints it and the function name, prints the
details, and aborts.

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I8bfab8c90cd1c18215fc0738f0b9504130f48b45

e020d13... by .eepp on 2020-04-21

lib: add bt_lib_log_v()

This is a `va_list` (vprintf() style) version of bt_lib_log().

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I41dc0e247c79e8f22cc930b27ec4f13a2dd6d573

4030a92... by .eepp on 2020-04-21


This adds a namespace as BT_ASSERT_PRE_MSG_CS_BEGIN_LE_END() is now part
of the common `assert-cond.h` header.

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I5f3197a41b240f58fb7da5518053c792aab5da9d

d5b13b9... by .eepp on 2020-04-16

lib: use common precond. assert. macros from `assert-cond.h` thru lib

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: Iad421161d61079f8777c4d75232e523a59f9120c

0a83319... by .eepp on 2020-04-21

lib: rename *_IS_TYPE() and *_HAS_ID() macros -> *_HAS_TYPE()

This is to normalize this type of macro.

Since those macros check that a given object _has_ a given type, I
believe "has" makes more sense than "is" (you pass the instance, not the

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I8b77443c3675d94ffc796b97eca2f773b71832db

2bdc32f... by .eepp on 2020-04-16

lib: commonize some precondition assertion macros

1. Rename `assert-cond.h` to `assert-cond-base.h`.

2. Move common specialized pre/postcondition macros from
   `assert-cond-base.h` to `assert-cond.h`.

   Now `assert-cond-base.h` only contains the very basic
   pre/postcondition assertion macros.

3. Move common specialized macros from various internal header files to

4. Add new common specialized macros to `assert-cond.h`, mostly "non
   null" precondition assertion macros.

The goal of this patch is to make it easy to change code for many sites
at the same time when those sites use the same macro.

This patch introduces the common precondition assertion macros, but
does not use them in source files (future patch).

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I2456e459bab9d942e4e11953b4afc5a6f4d30620

79545cc... by .eepp on 2020-04-16

lib: move bt_graph_configure() to `graph.c` (only used there)

Signed-off-by: Philippe Proulx <email address hidden>
Change-Id: I097f61f1e64d9e83d929980f5224b429e6202eb5
Reviewed-by: Simon Marchi <email address hidden>