Update working version to Babeltrace v2.0.7

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

Release: Babeltrace 2.0.6 "Amqui"

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

bt2: disable some warnings for `native_bt.c`

Replicate the changes done in the master branch by building native_bt.c
with the -Wno-unused-parameter and -Wno-missing-field-initializers
options.

Those changes were lifted from commits dd420a9 and ecd7492.

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

bt2: compile `native_bt.c` with `-Wno-undef`

As explained in the comment, work around a problem with SWIG 4.2.0.

Change-Id: Ia95fc1e4929591a0a16df48892b05f5e5df46be3
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11849
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11930
Reviewed-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: src.ctf.lttng-live: expect NEW_STREAM/METADATA for inactive streams

Observed issue
--------------

Some LTTng-tools live tests failures appear to show babeltrace2
hanging (failing to print expected events). The problem is intermittent,
but Kienan was able to develop a test case that's reproducible for him.

The test case performs the following steps:
  - Start a ust application and leave it running
  - Configure and then start an lttng live session
  - Connect a live viewer (babeltrace)
  - Run a second ust application
  - Wait for the expected number of events
    - In the failing case, no events are seen by babeltrace

Using per-uid buffers, the test typically completes normally. With
per-pid buffers the test fails, hanging indefinitely if waiting for the
specified number of events. While "hanging", babeltrace2 is polling the
relayd.

This affects for babeltrace2 stable-2.0 and master while using
lttng-tools master.

For more information, see the description of bug #1406[1]

Cause
-----

When consuming a live trace captured in per-PID mode, Babeltrace
periodically requests the index of the next packet it should consume.

As part of the reply, it gets a 'flags' field which is used to announce
that new streams, or new metadata, are available to the viewer.
Unfortunately, these 'flags' are only set when the relay daemon has new
tracing data to deliver. It is not set when the relay daemon indicates
that the stream is inactive (see LTTNG_VIEWER_INDEX_INACTIVE).

In the average case where an application is spawned while others are
actively emiting events, a request for new data will result in a reply
that returns an index entry (code LTTNG_VIEWER_INDEX_OK) for an
available packet accompanied by the LTTNG_VIEWER_FLAG_NEW_STREAM flag.

This flag indicates to the viewer that it should request new
streams (using the LTTNG_VIEWER_GET_NEW_STREAMS live protocol command)
before consuming the new data.

In the cases where we observe a hang, an application is running but not
emiting new events. As such, the relay daemon periodically emits "live
beacons" to indicate that the session's streams are inactive up to a
given time 'T'.

Since the existing application remains inactive and the viewer is never
notified that new streams are available, the viewer effectively remains
"stuck" and never notices the new application being traced.

The LTTNG_VIEWER_FLAG_NEW_METADATA communicates a similar semantic with
regards to the metadata. However, ignoring it for inactive streams isn't
as deleterious: the same information is made available to the viewer the
next time it will successfully request a new index to the relay daemon.

This would only become a problem if the tracers start to express
non-layout data (like supplemental environment information? but I don't
see a real use-case) as part of the metadata stream that should be made
available downstream even during periods of inactivity.

Note that the same problem most likely affects the per-UID buffer
allocation mode when multiple users are being traced.

Solution
--------

On the producer end, LTTNG_VIEWER_FLAG_NEW_STREAM is set even when
returning an inactivity index.

Note that to preserve compatibility with older live consumers that don't
expect this flag in non-OK response, the LTTNG_VIEWER_FLAG_NEW_STREAM
notification is repeated until the next LTTNG_VIEWER_GET_NEXT_INDEX
command that returns LTTNG_VIEWER_INDEX_OK.

On Babeltrace's end, the handler of the LTTNG_VIEWER_GET_NEXT_INDEX
command (lttng_live_get_next_index) is modified to expect
LTTNG_VIEWER_FLAG_NEW_STREAM in the cases where the command returns:
  - LTTNG_VIEWER_INDEX_OK (as done previously),
  - LTTNG_VIEWER_INDEX_HUP (new),
  - LTTNG_VIEWER_INDEX_INACTIVE (new).

Drawbacks
---------

This is arguably a protocol change as none of the producers ever set the
NEW_METADATA/NEW_STREAM flags when indicating an inactive stream.

References
----------

[1] https://bugs.lttng.org/issues/1406

Fixes #1406
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Icc7f90f5cb805f50ea16968396fe35454d30b4a8
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11587
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12188

Fix: `babeltrace2 convert`: don't consider the `--plugin-path` opt.

OBSERVED ISSUE
══════════════
When running the (default) `convert` command of the CLI and passing
`--plugin-path` _after_ a conversion argument, the program aborts:

    $ babeltrace2 /some/path --plugin-path=/meow/mix
    [1]    87823 IOT instruction (core dumped)  babeltrace2 /some/path --plugin-path=/meow/mix

I expect such a command line to gracefully tell me that `--plugin-path`
is an unknown option.

CAUSE
═════
This is due to the `convert` command considering the general
`--plugin-path` option (part of the `convert_options` array), but then
not ignoring it during one of its passes.

`--plugin-path` is a general option, not a conversion option. Therefore,
it must not be part of `--plugin-path`.

SOLUTION
════════
Remove the `OPT_PLUGIN_PATH` entry from the `convert_options` array in
`babeltrace2-cfg-cli-args.c`.

The output of the command line above is now:

    ERROR:    [Babeltrace CLI] (babeltrace2.c:2655)
      Command-line error: retcode=1
    CAUSED BY [Babeltrace CLI] (babeltrace2-cfg-cli-args.c:1427)
      While parsing `convert` command's command-line arguments: While
      parsing argument #3
      (`--plugin-path=data/plugins/src.ctf.fs/field/`): Unknown option
      `--plugin-path`

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

include/babeltrace2/plugin/plugin-dev.h: "define" -> "definition

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ic915ca902f7688386d9a66724ae417bf0952fd56
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11712
(cherry picked from commit 5ddcca6b643abb54940dd7b7640cc8f852ddccd1)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11713

Fix: doc: escape double quote in bt_p alias

The HTML doc shows some `<span class=` where the parameter names are
meant to appear.  Escape those double quotes to fix it.

The output was correct in the past, it only started to display the wrong
thing with this commit, in Doxygen 1.9.0:

https://github.com/doxygen/doxygen/commit/eb3d1eb5ad85c94d6f2c32934fce2b8630331d6c

Reported-By: Brice Videau <bvideau@anl.gov>
Change-Id: I61f3b557e3d8bf1428dd57e4c1ce950461e32479
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11647
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 95d759169cca3518352f539b6f87726b8cbb48e4)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11683
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: bt2: pass _TraceClassConst to destruction listeners

Trace class destruction listeners currently receive a _TraceClass.  I
think it's a mistake, in that they should receive a _TraceClassConst.
Fix that, tweak the tests to test it.  Test the same thing for trace
destruction listeners (they didn't suffer from the same issue).

Change-Id: I4651ffc44c916d64f6e6f2944fa856b4ed5bb5f6
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11447
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 2d6b60ff29423b918ac791f35d4f259178107cc1)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11709
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>

fix: 'load_module()' deprecated in Python 3.12

Starting with Python 3.10 we get the following warning:

  <frozen importlib._bootstrap>:283: DeprecationWarning: the
  load_module() method is deprecated and slated for removal in
  Python 3.12; use exec_module() instead

Replace our use of 'load_module()' with the recommended [1] alternative
that includes 'module_from_spec()' introduced in Python 3.5. Since we
need to support Python 3.4, keep the original code with a version check.

[1] https://docs.python.org/3.12/library/importlib.html#importlib.machinery.SourceFileLoader.load_module

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

tests: retry os.rename on PermissionError failure in lttng_live_server.py

On the Windows CI jobs, we get random failures like:

    # plugins/src.ctf.lttng-live/test-live.sh: python3 /c/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/src/babeltrace/tests/data/plugins/src.ctf.lttng-live/lttng_live_server.py /c/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/src/babeltrace/tests/data/plugins/src.ctf.lttng-live/inactivity-discarded-packet.json --port-file /c/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/tmp/test-live-server-port.Rn2dyS --trace-path-prefix C:\Users\jenkins\workspace\dev_review_babeltrace_master_winbuild\build\std\conf\std\platform\msys2-mingw64\src\babeltrace\tests\data\ctf-traces
    Traceback (most recent call last):
      File "C:/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/src/babeltrace/tests/data/plugins/src.ctf.lttng-live/lttng_live_server.py", line 1951, in <module>
        LttngLiveServer(port, port_filename, sessions, max_query_data_response_size)
      File "C:/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/src/babeltrace/tests/data/plugins/src.ctf.lttng-live/lttng_live_server.py", line 1667, in __init__
        self._write_port_to_file(port_filename)
      File "C:/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/src/babeltrace/tests/data/plugins/src.ctf.lttng-live/lttng_live_server.py", line 1792, in _write_port_to_file
        os.replace(tmp_port_file.name, port_filename)
    PermissionError: [WinError 5] Access is denied: 'C:/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/tmp/tmpt13jh6sp' -> 'C:/Users/jenkins/workspace/dev_review_babeltrace_master_winbuild/build/std/conf/std/platform/msys2-mingw64/tmp/test-live-server-port.Rn2dyS'

The PermissionError exception is raised when trying to move the port
file from its temporary location to its final location, where the bash
script expects it to appear.

I don't understand the root cause of the issue.  When exiting the `with`
scope, the temporary file is supposed to be closed, and it should be
fine to move it.  I suppose it's possible that something in the Windows
kernel hasn't completely finished using the file when we try to move it.

Implement a wait-and-retry scheme as a (bad) workaround.

Change-Id: Ia8dcefca9538aa5e58438bf84a3fa67e5e05a49a
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11174
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 6362d281d2fce21fbb610bae0cabaee4f73c3415)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11224
Tested-by: jenkins <jenkins@lttng.org>
CI-Build: Michael Jeanson <mjeanson@efficios.com>

doc: fix uptream -> upstream typos

Change-Id: Ic52f47c1b3fbbeb2db6da260c1d75570ec6542d5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/8742
CI-Build: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 437ed44dbbb8a04e0bcb62c092b7e8b7471b98a2)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11089

fix: test_message_iterator.py hangs on Python 3.12

Starting with Python 3.12 'None' is immortal, its refcount operations
are NO-OP and sys.getrefcount() will return a static value of UINT_MAX
on 64-bit and UINT_MAX >> 2 on 32-bit.

This basically transform 'test_try_again_many_times' in an almost
infinite loop and hangs the testsuite.

Detect this by checking if the refcount on 'None' is incremented after
assigning to a variable and skip the test if it's not the case.

See PEP-0683[1] for the gory details.

[1] https://peps.python.org/pep-0683/

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

plugin-dev: mark symbols meant to be public with __attribute__((visibility("default")))

This is a partial backport of commit 1353b066072 ("Visibility hidden by
default"), from the master branch.

If a plugin author compiles their plugin with `-fvisibility=hidden`,
symbols such as `__bt_get_begin_section_plugin_descriptor` are local,
therefore not seen by libbbabeltrace2, and the plugin fails to load.

To avoid this, use `__attribute__((visibility("default")))` on those
symbols that we really want to be externally visible.

Reported-By: Kienan Stewart <kstewart@efficios.com>
Change-Id: Ia08173fa69ed699583a0957ce42f305d443b2952
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11111
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Kienan Stewart <kstewart@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Silence -Wunused-but-set-variable error with clang

When building with clang-15, I get:

      CXX      libctf_parser_la-parser.lo
    parser.cpp:2920:9: error: variable 'yynerrs' set but not used [-Werror,-Wunused-but-set-variable]
        int yynerrs;
            ^

This is because it warns for something like this:

    int n;
    n = 0;
    ++n;

whereas previous versions do not.

This is generated code, so there's not much more we can do other than
silence the warning for the file.

Change-Id: If2cffe9042b743ffe4b4b23f751216f67b58e5fa
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/8655
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 2ea09241f07f1dfd4b6fd0f2f296a10142fda7d2)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11116
CI-Build: Michael Jeanson <mjeanson@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>

Fix: Windows DLL path lookup with Python >= 3.8

Starting with Python 3.8 on Windows [1] the DLLs lookup when loading
native modules was changed to not search PATH like everything else on
this platform. Restore this behavior by doing it manually.

Simon adds: it only started to matter now because MSYS2 dropped a local
patch [2] that retained the old behaviour.

[1]: https://docs.python.org/3/library/os.html#os.add_dll_directory
[2]: https://www.msys2.org/news/#2023-08-06-python-changed-behavior-when-loading-dll-dependencies-of-extension-modules

Change-Id: Id436244a717f440db11c33b6d418f31c7838591d
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11043
(cherry picked from commit 86f24b106e04c81bf252f2a4b1b99ad99b938de8)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11115
Tested-by: jenkins <jenkins@lttng.org>

doc/man: make default values of boolean init. params. clearer

This patch answers to <https://bugs.lttng.org/issues/1387>, removing the
"=`yes`" and "=`no`" in the component class manual pages to replace them
with "='VAL'" and indicate the behaviour depending on "'VAL'", as well
as the default value.

Fixes: https://bugs.lttng.org/issues/1387
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ie7439fa397e2a9a5818152a68073f7bf87385675
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10709
(cherry picked from commit 6f6e5e6146d1d55f9d49b587a64e2b32ebc29064)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10726

RFC: docs: fix: Match stated automake requirement

to the applied requirement. Previously the README stated the minimum
required version of automake was 1.10, but the configuration script
(configure.ac) actually enforced a minimum of 1.12:

AM_INIT_AUTOMAKE([1.12 foreign dist-bzip2 no-dist-gzip ...

Change-Id: Ia3329a4f1e5e1cfe8a0444b758d068e81416d506
Signed-off-by: Erica Bugden <ebugden@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10587
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

fix: make flake8 6.x happy

./src/bindings/python/bt2/bt2/trace_collection_message_iterator.py:143:12: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
./src/bindings/python/bt2/bt2/trace_collection_message_iterator.py:151:12: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
./src/bindings/python/bt2/bt2/trace_collection_message_iterator.py:156:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
./src/bindings/python/bt2/bt2/trace_collection_message_iterator.py:160:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
./src/bindings/python/bt2/bt2/trace_collection_message_iterator.py:164:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
./src/bindings/python/bt2/bt2/trace_collection_message_iterator.py:168:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
./tests/data/auto-source-discovery/params-log-level/bt_plugin_test.py:33:20: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`

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

fix: running black on python 3.11

Black 22.0 is incompatible with click >= 8.1 [1], pin it to a working
version.

Traceback (most recent call last):
  File ".pyenv/bin/black", line 8, in <module>
    sys.exit(patched_main())
             ^^^^^^^^^^^^^^
  File ".pyenv/lib/python3.11/site-packages/black/__init__.py", line 6606, in patched_main
    patch_click()
  File ".pyenv/lib/python3.11/site-packages/black/__init__.py", line 6595, in patch_click
    from click import _unicodefun  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ImportError: cannot import name '_unicodefun' from 'click' (.pyenv/lib/python3.11/site-packages/click/__init__.py)

[1] https://github.com/psf/black/issues/2964

Change-Id: I502f10e4cdedae4c431a243fc621fa10ab8bc5cf
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10604
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10618

bt_query_executor_create_with_method_data(): fix docs note

The bt_graph_add_*_component*() functions accept a `params` parameter,
not the bt_graph_add_*_component_*_port_added_listener() ones.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib2b8fa0177a8915d344ccaf3e55c05d3c939d2ca
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10559
(cherry picked from commit 9734640065c7fb1674d13f7e1e2ab62f54bde567)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10566

Fix: ctf-writer: null dereference in bt_ctf_trace_common_add_stream_class

Cherry-pick note: I (Simon) see this error when building on the CI's ppc
machine, although I don't see it on the CI job.

gcc 12.1.0 reports that:
In file included from object-pool.h:38,
                 from clock-class.h:11,
                 from trace.c:27:
In function 'bt_ctf_object_set_parent',
    inlined from 'bt_ctf_object_set_parent' at object.h:102:6,
    inlined from 'bt_ctf_trace_common_add_stream_class' at trace.c:1227:3:
object.h:123:26: warning: null pointer dereference [-Wnull-dereference]
  123 |                 if (child->parent) {
      |                     ~~~~~^~~~~~~~
object.h:123:26: warning: null pointer dereference [-Wnull-dereference]

This can indeed happen if bt_ctf_trace_common_add_stream_class is called
with a nil stream class argument. A null check is added in the error
path.

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

Update working version to Babeltrace v2.0.6

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

Release: Babeltrace 2.0.5 "Amqui"

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

bt2: honor build system compiler/linker preferences

Cherry-pick note: I see the following build failure on Arch Linux:

    ccache gcc -DNDEBUG -g -fwrapv -O3 -Wall -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/python/src=/usr/src/debug/python -flto=auto -ffat-lto-objects -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/python/src=/usr/src/debug/python -flto=auto -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/python/src=/usr/src/debug/python -flto=auto -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -pthread -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -pthread -fno-strict-aliasing -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wdeclaration-after-statement -Wimplicit-function-declaration -Wold-style-definition -Wjump-misses-init -Wall -Wextra -Wundef -Wwrite-strings -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wno-unused-parameter -Wno-missing-field-initializers -Wformat=2 -Wcast-align -Wformat-nonliteral -Wformat-security -Wsign-compare -Wstrict-aliasing -Wshadow -Winline -Wpacked -Wmissing-format-attribute -Wmissing-noreturn -Winit-self -Wmissing-include-dirs -Wunused-but-set-variable -Warray-bounds -Wreturn-type -Wswitch-enum -Wswitch-default -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict -Wnull-dereference -Wdouble-promotion -Wno-sign-compare -Wno-inline -Wno-declaration-after-statement -Wno-switch-enum -Wno-switch-default -Wno-packed -Wno-pointer-arith -Wno-format-nonliteral -Wno-double-promotion -Wno-cast-align -Wno-cast-function-type -Wno-suggest-attribute=format -Werror -Wno-error=unused-parameter -Wno-error=missing-field-initializers -Wno-error=sign-compare -Wno-error=inline -Wno-error=declaration-after-statement -Wno-error=switch-enum -Wno-error=switch-default -Wno-error=packed -Wno-error=pointer-arith -Wno-error=format-nonliteral -Wno-error=double-promotion -Wno-error=cast-align -Wno-error=cast-function-type -Wold-style-definition -Werror=implicit-function-declaration -g3 -O0 -fmax-errors=1 -fdiagnostics-color=always -Wno-shadow -Wno-null-dereference -Wno-deprecated-declarations -Wno-redundant-decls -I/home/smarchi/src/babeltrace/include -I../../../../src -I/home/smarchi/src/babeltrace/src -include common/config.h -I/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2 -fPIC -I/usr/include/python3.11 -c /home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/logging.c -o build/temp.linux-x86_64-3.11/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/logging.o
    In file included from /usr/include/errno.h:25,
                     from /home/smarchi/src/babeltrace/src/logging/log.h:12,
                     from /home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/logging.c:24:
    /usr/include/features.h:413:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
      413 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
          |    ^~~~~~~

Cherry-picking this patch fixes it.  And now the original commit
message:

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

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

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

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

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

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

This is due to the fact that:

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

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

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

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

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

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

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

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

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

The fix
-------

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

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

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

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

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

Drawbacks
---------

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

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

Fix: clear_string_field(): set first character to 0

The API documentation of bt_field_string_clear() says:

> Clears the string field `field`, making its value an empty string.

clear_string_field(), called by bt_field_string_clear(), sets the string
field's buffer's length to 0 without setting its first character to 0 to
make the string field empty from bt_field_string_get_value()'s point of
view.

This patch makes clear_string_field() also set the string field's
buffer's first character to 0.

Reported by Brice Videau (@Kerilk) in
<https://github.com/efficios/babeltrace/pull/116>.

Reported-by: Brice Videau <bvideau@anl.gov>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I964599ecfbea33a7cb583dcf7cf25e6cffbc30b6
Reviewed-on: https://review.lttng.org/c/babeltrace/+/4528
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
(cherry picked from commit 0022a87819b0908869f99e08925d2d71c150b285)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10010
CI-Build: Simon Marchi <simon.marchi@efficios.com>

Fix: src.ctf.fs: Not resolving event common ctx

Issue
=====
An assertion fails when creating the trace class with a sequence in the
event common context with the following callstack:
  #0  0x00007ffff7bf118b in raise () from /lib/x86_64-linux-gnu/libc.so.6
  #1  0x00007ffff7bd0859 in abort () from /lib/x86_64-linux-gnu/libc.so.6
  #2  0x00007ffff73e2d86 in bt_common_abort () at common.c:2111
  #3  0x00007ffff73ddec4 in bt_common_assert_failed (file=0x7ffff73ec268 "ctf-meta-update-value-storing-indexes.c", line=57, func=0x7ffff73ec300 <__func__.16976> "update_field_class_stored_value_index", assertion=0x7ffff73ec260 "tgt_fc") at assert.c:40
  #4  0x00007ffff738a396 in update_field_class_stored_value_index (fc=0x5555555d9c00, tc=0x555555598000, sc=0x555555598690, ec=0x0) at ctf-meta-update-value-storing-indexes.c:57
  #5  0x00007ffff738a4a0 in update_field_class_stored_value_index (fc=0x5555555d8ee0, tc=0x555555598000, sc=0x555555598690, ec=0x0) at ctf-meta-update-value-storing-indexes.c:81
  #6  0x00007ffff738a63b in ctf_trace_class_update_value_storing_indexes (ctf_tc=0x555555598000) at ctf-meta-update-value-storing-indexes.c:148
  #7  0x00007ffff73a0e95 in ctf_visitor_generate_ir_visit_node (visitor=0x55555559ce60, node=0x5555555ad100) at visitor-generate-ir.c:4900
  #8  0x00007ffff738e583 in ctf_metadata_decoder_append_content (mdec=0x55555559f380, fp=0x5555555aba00) at decoder.c:316
  #9  0x00007ffff73c9fda in ctf_fs_metadata_set_trace_class (self_comp=0x5555555a21b0, ctf_fs_trace=0x5555555981d0, config=0x55555559ee08) at metadata.c:107
  #10 0x00007ffff73c5e2f in ctf_fs_trace_create (self_comp=0x5555555a21b0, self_comp_class=0x0, path=0x555555597d40 "/home/frdeso/lttng-traces/auto-20210804-093702/kernel", name=0x0, metadata_config=0x55555559ee08, log_level=BT_LOGGING_LEVEL_WARNING) at fs.c:1072
  #11 0x00007ffff73c65cc in ctf_fs_component_create_ctf_fs_trace_one_path (ctf_fs=0x55555559edf0, path_param=0x5555555a1e50 "/home/frdeso/lttng-traces/auto-20210804-093702/kernel", trace_name=0x0, traces=0x555555597a80, self_comp=0x5555555a21b0, self_comp_class=0x0) at fs.c:1183
  #12 0x00007ffff73c8a4d in ctf_fs_component_create_ctf_fs_trace (ctf_fs=0x55555559edf0, paths_value=0x5555555ac4d0, trace_name_value=0x0, self_comp=0x5555555a21b0, self_comp_class=0x0) at fs.c:2097
  #13 0x00007ffff73c9a97 in ctf_fs_create (params=0x5555555abf70, self_comp_src=0x5555555a21b0) at fs.c:2397
  #14 0x00007ffff73c9b52 in ctf_fs_init (self_comp_src=0x5555555a21b0, config=0x0, params=0x5555555abf70, init_method_data=0x0) at fs.c:2431
  #15 0x00007ffff7f20b60 in add_component_with_init_method_data (graph=0x5555555a20a0, comp_cls=0x5555555a9580, init_method=0x7ffff73c9b1c <ctf_fs_init>, name=0x5555555abf40 "auto-disc-source-ctf-fs", params=0x5555555abf70, init_method_data=0x0, log_level=BT_LOGGING_LEVEL_WARNING, user_component=0x7fffffffe308, api_func=0x7ffff7f63880 <__func__.17336> "bt_graph_add_source_component", init_method_name=0x7ffff7f633a8 "bt_component_class_source_initialize_method") at graph.c:1048
  #16 0x00007ffff7f20e3d in add_source_component_with_initialize_method_data (graph=0x5555555a20a0, comp_cls=0x5555555a9580, name=0x5555555abf40 "auto-disc-source-ctf-fs", params=0x5555555abf70, init_method_data=0x0, log_level=BT_LOGGING_LEVEL_WARNING, component=0x7fffffffe308, api_func=0x7ffff7f63880 <__func__.17336> "bt_graph_add_source_component") at graph.c:1127
  #17 0x00007ffff7f20eec in bt_graph_add_source_component (graph=0x5555555a20a0, comp_cls=0x5555555a9580, name=0x5555555abf40 "auto-disc-source-ctf-fs", params=0x5555555abf70, log_level=BT_LOGGING_LEVEL_WARNING, component=0x7fffffffe308) at graph.c:1152
  #18 0x000055555556251a in cmd_run_ctx_create_components_from_config_components (ctx=0x7fffffffe390, cfg_components=0x5555555ab0c0) at babeltrace2.c:2252
  #19 0x00005555555628ec in cmd_run_ctx_create_components (ctx=0x7fffffffe390) at babeltrace2.c:2347
  #20 0x0000555555562cb5 in cmd_run (cfg=0x5555555a1b80) at babeltrace2.c:2461
  #21 0x00005555555635ef in main (argc=2, argv=0x7fffffffe508) at babeltrace2.c:2673

This is due to the fact that the event context field class containing a
sequence is never resolved by calling `resolve_root_class()`. This leads
to the `ctf_field_class_sequence::length_fc` field never being
initialized.

Looking at the `resolve_stream_class_field_classes()` function, it looks
like there is a typo where the `CTF_SCOPE_EVENT_SPECIFIC_CONTEXT` enum
label was used where the intention was to use
`CTF_SCOPE_EVENT_COMMON_CONTEXT` according to the surrounding code.

Fix
===
Replace `CTF_SCOPE_EVENT_SPECIFIC_CONTEXT` by `CTF_SCOPE_EVENT_COMMON_CONTEXT`.

Test
====
This commit adds a minimal testcase with a sequence in the event and
packet contexts.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I370a620855f2dcdf51d02db80b9df22b0f043f3a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/6257
CI-Build: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
(cherry picked from commit 524e73a1580c5c4dac9359177ba6da2577424642)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10011
CI-Build: Simon Marchi <simon.marchi@efficios.com>

debug-info: fix -Wenum-int-mismatch problem in copy_field_class_content_internal

GCC 13 points out that the return value differs between the declaration
and definition of copy_field_class_content_internal, fix that.

      CC       trace-ir-metadata-field-class-copy.lo
    cc1: warning: command-line option '-Wsuggest-override' is valid for C++/ObjC++ but not for C
    /home/smarchi/src/babeltrace/src/plugins/lttng-utils/debug-info/trace-ir-metadata-field-class-copy.c:885:41: error: conflicting types for 'copy_field_class_content_internal' due to enum/integer mismatch; have 'enum debug_info_trace_ir_mapping_status(struct trace_ir_metadata_maps *, const bt_field_class *, bt_field_class *)' [-Werror=enum-int-mismatch]
      885 | enum debug_info_trace_ir_mapping_status copy_field_class_content_internal(
          |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In file included from /home/smarchi/src/babeltrace/src/plugins/lttng-utils/debug-info/trace-ir-metadata-field-class-copy.c:22:
    /home/smarchi/src/babeltrace/src/plugins/lttng-utils/debug-info/trace-ir-metadata-field-class-copy.h:17:5: note: previous declaration of 'copy_field_class_content_internal' with type 'int(struct trace_ir_metadata_maps *, const bt_field_class *, bt_field_class *)'
       17 | int copy_field_class_content_internal(struct trace_ir_metadata_maps *trace_ir_metadata_maps,
          |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Change-Id: I9c0dd3ffc3ba1a2e9fbbca948a391357ae28a483
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9986
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit f4e2bc6a8ab9f8c1557904d36151c691f726477c)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10009

fix: pass exec-prefix to python bindings install

Some systems will split the arch independent files from the arch
specific using a different value for 'prefix' and 'exec-prefix'. Pass
this information from the Makefile to the python build system.

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

fix: document proper Bison version requirement

The minimum version of Bison was bumped to 2.5 a while ago, update the
documentation and help messages that still refer to 2.4.

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

cli: use return value of g_string_free

When building against glib 2.76, I see:

      CC       babeltrace2-cfg-cli-args.o
    In file included from /usr/include/glib-2.0/glib/giochannel.h:36,
                     from /usr/include/glib-2.0/glib.h:56,
                     from /home/simark/src/babeltrace/src/common/assert.h:12,
                     from /home/simark/src/babeltrace/src/logging/log.h:27,
                     from /home/simark/src/babeltrace/src/cli/logging.h:11,
                     from /home/simark/src/babeltrace/src/cli/babeltrace2-cfg-cli-args.c:10:
    /home/simark/src/babeltrace/src/cli/babeltrace2-cfg-cli-args.c: In function ‘plugin_comp_cls_names’:
    /usr/include/glib-2.0/glib/gstring.h:72:5: error: ignoring return value of ‘g_string_free_and_steal’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
       68 |   (__builtin_constant_p (free_segment) ?        \
          |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       69 |     ((free_segment) ?                           \
          |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       70 |       (g_string_free) ((str), (free_segment)) : \
          |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       71 |       g_string_free_and_steal (str))            \
          |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       72 |     :                                           \
          |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       73 |     (g_string_free) ((str), (free_segment)))
          |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/simark/src/babeltrace/src/cli/babeltrace2-cfg-cli-args.c:136:25: note: in expansion of macro ‘g_string_free’
      136 |                         g_string_free(gs_name, FALSE);
          |                         ^~~~~~~~~~~~~

glib made g_string_free warn about unused results in this commit:

  https://gitlab.gnome.org/GNOME/glib/-/commit/c3d07a625a407b56432f4b8c60295fd32ee1ee2b

Fix that by changing our code to get the released value from the return
value of g_string_free, rather than doing it in two steps..  No
functional changes intended.

Change-Id: I62f4002d0487165b7c9d33f471937185f3bc0f82
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9728
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 2e4a3da35892bf53e49936532a3a04e4c6819cb3)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9889
CI-Build: Simon Marchi <simon.marchi@efficios.com>

babeltrace2-query(1): erroneous parameter used in example

The src.ctf.fs component class expects the `inputs` parameter (an array
of strings) rather than `path` (a string).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Id716d68cbb289fe7b52f10c22ed6bc5c9914e2e4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9867
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit a2aea8a8a071beb7316ade918b824ebd51ac8cf7)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9886

Fix: tests: print real values in a fixed format

The cli_params_to_string.to_string function converts float values
(bt2._RealValueConst) to string using the str function.  The format of
that seems to differ across platform.  On a 32-bit powerpcspe platform,
we see this failure in the cli/params/test_params test:

  -{a=10500000.0, b=10500000.0, c=1.05e-05, d=1.05e-05}
  +{a=10500000.0, b=10500000.0, c=1.0499999999999999e-05, d=1.0499999999999999e-05}

Fix that by doing an explicit string conversion for _RealValueConst objects,
with a constant 7 decimal places after the decimal point.  The 7 is chosen so
that the numbers in tests in cli/params/test_params are not truncated.

Change-Id: Ie4fcb8eb422c3d44eeec1201169dc8a995536d4a
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9651
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
(cherry picked from commit 5b616db96266d25cb0749e472cfc78c4944675e2)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9660

Fix: bt2: autodisc: remove thread error while inserting status in map

If something fails in `bt_bt2_auto_discover_source_components`, we
append an error cause and we go to the error label.  This function
returns a bt_value map containing the return status code and the auto-discovery results, if it was successful.
So we then run into:

if (result) {
insert_entry_status = bt_value_map_insert_signed_integer_entry(result, "status", status);
if (insert_entry_status != BT_VALUE_MAP_INSERT_ENTRY_STATUS_OK) {
BT_VALUE_PUT_REF_AND_RESET(result);
PyErr_NoMemory();
}
}

However, since there is an error on the current thread, we fail this
precondition:

    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:64 Babeltrace 2 library precondition not satisfied.
    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:66 ------------------------------------------------------------------------
    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:67 Condition ID: `pre:value-map-insert-signed-integer-entry:no-error`.
    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:69 Function: bt_value_map_insert_signed_integer_entry().
    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:70 ------------------------------------------------------------------------
    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:71 Error is:
    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:73 API function called while current thread has an error: function=bt_value_map_insert_signed_integer_entry
    06-30 11:27:11.697 3948806 3948806 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:76 Aborting...

Change the function to temporarily remove the current thread error,
while inserting the status in the map.  In the unlikely event where the
insertion fail because of a memory error, then we just release the error
and it gets lost.

Cherry-pick note
----------------

Just like the previous commit, the error string expected by the test had
to be updated.

Change-Id: I1b54fb7c8cb0f719fee867e7385dd6a3949cbde4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/8512
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 827e42e017fc5f525aa39a3851bf2e7e50e887aa)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9512
Tested-by: jenkins <jenkins@lttng.org>

tests: src.ctf.fs: add test for metadata with invalid syntax

It looks like we don't have any test for a metadata file with a syntax
error in it.  Add one.

It could be argued that we should not error out in that case, as there
may be unrelated files called `metadata`, and if they don't parse as CTF
1 metadata files, we should just skip over them.  But erroring out is
the current behavior of Babeltrace 2, so it should be tested to ensure
it doesn't change by mistake.

Cherry-pick note
----------------
The test needed to be adjusted to look for:

  Component class's "query" method failed:

instead of

  At line 3 in metadata stream: syntax error, unexpected CTF_RSBRAC: token=\"]\""

because the stable-2.0 branch does not include the patch that makes the
CTF metadata reader append error causes (50f6fce8d00b ("ctf: append
error causes when returning errors")).  The test is still relevant, as
it catches an assertion failure that would crash babeltrace.

Change-Id: I82cae8ebc5df984592205c28041276cc861f30df
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/8511
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit dfa664f9be160bace24f960b444818d06e75aeb5)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9532
Tested-by: jenkins <jenkins@lttng.org>

tests: shorten names of session-rotation trace

Filenames of this trace on the CI are too long for Windows, causing test
failures.  Shorten some directory names to avoid that

Change-Id: I8d936af3efca894d55a94a57e3a3d4d5b0441305
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/8694
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
(cherry picked from commit 8dea686a2397bdadb81f44a3e74fd39fd7397ee2)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9549
Tested-by: jenkins <jenkins@lttng.org>

bt2: ignore -Wredundant-decls warning

The ppc builder on the CI, which uses Python 3.11 + gcc 12.2.0, shows
this warning:

    In file included from /usr/include/python3.11/Python.h:91,
                     from bt2/native_bt.c:168:
    /usr/include/python3.11/modsupport.h:37:24: error: redundant redeclaration of ‘_Py_BuildValue_SizeT’ [-Werror=redundant-decls]
       37 | PyAPI_FUNC(PyObject *) _Py_BuildValue_SizeT(const char *, ...);
          |                        ^~~~~~~~~~~~~~~~~~~~
    /usr/include/python3.11/modsupport.h:20:41: note: previous declaration of ‘_Py_BuildValue_SizeT’ with type ‘PyObject *(const char *, ...)’ {aka ‘struct _object *(const char *, ...)’}
       20 | #define Py_BuildValue                   _Py_BuildValue_SizeT
          |                                         ^~~~~~~~~~~~~~~~~~~~
    /usr/include/python3.11/modsupport.h:36:24: note: in expansion of macro ‘Py_BuildValue’
       36 | PyAPI_FUNC(PyObject *) Py_BuildValue(const char *, ...);
          |                        ^~~~~~~~~~~~~

I tried fixing it by placing some push/ignored/pop diagnostic pragmas in
the SWIG sections %begin and %runtime, which would be around the
Python.h including in the generated native_bt.c file, but it doesn't
silence the warning for some reason.

Ignore the warning for the whole native_bt.c compilation instead.

Change-Id: Idae04fb30af8108ad14647d9b8f85b2d01a568be
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
(cherry picked from commit 92e41f9132ac72f234deb2f39f2eae0b1858cfc0)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9567
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

ctf: fix -Wformat-overflow error in ctf-meta-resolve.cpp

Fix this, seen when building with -O2 with gcc 12.2.1:

      CXX      ctf-meta-resolve.lo
    In file included from ../../../../../src/logging/comp-logging.h:16,
                     from ctf-meta-resolve.cpp:12:
    In function 'int pathstr_to_field_path(const char*, ctf_field_path*, resolve_context*)',
        inlined from 'int resolve_sequence_or_variant_field_class(ctf_field_class*, resolve_context*)' at ctf-meta-resolve.cpp:948:32,
        inlined from 'int resolve_field_class(ctf_field_class*, resolve_context*)' at ctf-meta-resolve.cpp:1026:54:
    ../../../../../src/logging/comp-logging.h:18:41: error: '%s' directive argument is null [-Werror=format-overflow=]
       18 | #define _BT_COMP_LOG_COMP_PREFIX        "[%s] "
    ../../../../../src/logging/log.h:815:67: note: in definition of macro 'BT_LOG_WRITE'
      815 |                                                         lvl, tag, __VA_ARGS__); \
          |                                                                   ^~~~~~~~~~~
    ../../../../../src/logging/comp-logging.h:23:42: note: in expansion of macro '_BT_COMP_LOG_COMP_PREFIX'
       23 |         BT_LOG_WRITE((_lvl), BT_LOG_TAG, _BT_COMP_LOG_COMP_PREFIX _fmt, \
          |                                          ^~~~~~~~~~~~~~~~~~~~~~~~
    ../../../../../src/logging/comp-logging.h:83:9: note: in expansion of macro 'BT_COMP_LOG'
       83 |         BT_COMP_LOG(BT_LOG_DEBUG, (BT_COMP_LOG_SELF_COMP), _fmt, ##__VA_ARGS__)
          |         ^~~~~~~~~~~
    ctf-meta-resolve.cpp:650:9: note: in expansion of macro 'BT_COMP_LOGD'
      650 |         BT_COMP_LOGD("Found field path: path=\"%s\", field-path=\"%s\"", pathstr,
          |         ^~~~~~~~~~~~

Change-Id: Ib311185359a531f3e14bfbbbe6726aa633ceb3e4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
(cherry picked from commit ceda1ae6ecf09cd6ad521b34b553f78dbe9bec21)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9548
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

ctf-writer: fix -Wformat-overflow errors in resolve.c

Fix these, seen when building with -O2 with gcc 12.2.1:

      CC       resolve.lo
    In file included from logging.h:11,
                     from resolve.c:11:
    In function 'pathstr_to_field_path',
        inlined from 'resolve_sequence_or_variant_type' at resolve.c:1004:22,
        inlined from 'resolve_type' at resolve.c:1105:9:
    resolve.c:667:25: error: '%s' directive argument is null [-Werror=format-overflow=]
      667 |                 BT_LOGT("Found field path: path=\"%s\", field-path=\"%s\"",
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../../src/logging/log.h:815:67: note: in definition of macro 'BT_LOG_WRITE'
      815 |                                                         lvl, tag, __VA_ARGS__); \
          |                                                                   ^~~~~~~~~~~
    resolve.c:667:17: note: in expansion of macro 'BT_LOGT'
      667 |                 BT_LOGT("Found field path: path=\"%s\", field-path=\"%s\"",
          |                 ^~~~~~~
    resolve.c: In function 'resolve_type':
    resolve.c:667:70: note: format string is defined here
      667 |                 BT_LOGT("Found field path: path=\"%s\", field-path=\"%s\"",
          |                                                                      ^~
    In function 'get_field_paths_lca_index',
        inlined from 'validate_target_field_path' at resolve.c:901:15,
        inlined from 'resolve_sequence_or_variant_type' at resolve.c:1026:8,
        inlined from 'resolve_type' at resolve.c:1105:9:
    resolve.c:792:25: error: '%s' directive argument is null [-Werror=format-overflow=]
      792 |                 BT_LOGT("Finding lowest common ancestor (LCA) between two field paths: "
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../../src/logging/log.h:815:67: note: in definition of macro 'BT_LOG_WRITE'
      815 |                                                         lvl, tag, __VA_ARGS__); \
          |                                                                   ^~~~~~~~~~~
    resolve.c:792:17: note: in expansion of macro 'BT_LOGT'
      792 |                 BT_LOGT("Finding lowest common ancestor (LCA) between two field paths: "
          |                 ^~~~~~~
    resolve.c:792:25: error: '%s' directive argument is null [-Werror=format-overflow=]
      792 |                 BT_LOGT("Finding lowest common ancestor (LCA) between two field paths: "
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../../src/logging/log.h:815:67: note: in definition of macro 'BT_LOG_WRITE'
      815 |                                                         lvl, tag, __VA_ARGS__); \
          |                                                                   ^~~~~~~~~~~
    resolve.c:792:17: note: in expansion of macro 'BT_LOGT'
      792 |                 BT_LOGT("Finding lowest common ancestor (LCA) between two field paths: "
          |                 ^~~~~~~

Change-Id: I91608a4e782a4059225986dd974130ccbaf54207
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
(cherry picked from commit 39630c3ba7000fc6c9337b2420bbeba2d9d7c723)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/9547
Tested-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: src.text.details: use write_uint_prop_value to handle unsigned values in write_int_range

I tried creating an option field class with unsigned integer selector,
with a [1, UINT64_MAX] range.  The details field class shows it as:

     opt_with_uint_sel: Option (unsigned integer selector) (Selector field location [Event payload: uint_selector]):
      Selector ranges: [1, -1]

The -1 is wrong.  Fix two spots to call write_uint_prop_value instead of
write_int_prop_value.

After:

    opt_with_uint_sel: Option (unsigned integer selector) (Selector field location [Event payload: uint_selector]):
       Selector ranges: [1, 18,446,744,073,709,551,615]

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

Add `dev-requirements.txt` for pip

`dev-requirements.txt` contains which specific version of Black and
Flake8 to use for development and by a CI so that both parties agree.

Use specific versions as such:

    $ virtualenv -p python3 yo
    $ . yo/bin/activate
    $ pip install -r dev-requirements.txt

Change-Id: Id29e7f61c4038b55bed613e00f76f7c180699fa9
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: src.ctf.lttng-live: consider empty metadata packet as retry

When clearing a live session, it's possible for the Relay to know that
metadata is available even though it has not yet received it from the
consumer.

In such cases, the relay will send a `LTTNG_VIEWER_METADATA_OK` reply
with a zero length metadata packet. The viewer needs to interpret that
as "please try again later". In fact, the viewer needs to keep
requesting metadata from the relay until it receives either a
`LTTNG_VIEWER_NO_NEW_METADATA` status or an error status.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ief33f1a43ec827e211a2f4f2ace623e9d3254246
Reviewed-on: https://review.lttng.org/c/babeltrace/+/7392

Fix: ctf: wrongfully requiring CTF metadata signature for every section

Issue
=====
When testing the special live tracing session case of sending the
metadata in multiple batches, we witnessed the CTF metadata decoder
returning an error if the "/* CTF 1.8" signature is omitted from the
metadata sections following the first one.

Here is the output of Babeltrace when this error occurs:
    07-22 12:18:38.518 539222 539222 W PLUGIN/CTF/META/DECODER ctf_metadata_decoder_append_content@decoder.c:242 [lttng-live] Missing "/* CTF major.minor" signature in plain text metadata file stream: mdec-addr=0x2398ec0
    07-22 12:18:38.518 539222 539222 E PLUGIN/CTF/META/DECODER ctf_metadata_decoder_append_content@decoder.c:251 [lttng-live] Invalid metadata version found in plain text signature: version=571641920.0, mdec-addr=0x2398ec0

We expect the decoder to only require this signature when decoding the
first section of plain-text metadata.

Solution
========
Only check for the signature when processing the first metadata section.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3153abf58ade5f5b02362dbedde382f398f5ee4e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/7391

Fix: src.ctf.lttng-live: session closed before any metadata is received

Issue
=====
When stress-testing the LTTng-UST clear feature over an entire night I
witnessed 6 instances of Babeltrace infinite loop.

Using the GNU Debugger, Babeltrace was found to be endlessly issuing the
`LTTNG_VIEWER_GET_NEW_STREAMS` command to the Relay daemon to which the
Relay Daemon endlessly replied `LTTNG_VIEWER_NEW_STREAMS_HUP`.

This is caused by the fact that the session was closed before we
received any metadata and the lttng-live component class keeps trying to
ask for new streams before requesting the metadata.

Fix
===
If the session is marked as closed return a `_STATUS_END` to stop
considering this session.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I9c18d03cef1b61d1c02b7d608720bf5750a348c4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/7390

fix: obsolete warnings with autoconf >= 2.71

Disable 'obsolete' warnings when running autoreconf, on systems with
autoconf >= 2.71 the glib2 macros which we have no control over will
trigger warnings, which then confuses jenkins's compiler warnings
detection code and fails the jobs.

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

fix: explicitly disable '-Wsuggest-attribute=format'

Some older GCC version seems to enable '-Wsuggest-attribute=format' with
'-Wall' which results in unwanted warnings. Fixing this would require
modifications to the public headers which were done in the master
branch. As a fix for this stable branch, explicitly disable this warning
if the compiler supports it.

Change-Id: Ic71a9d0986c6f3d1eae561b15c8ffad54773e825
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

fix: set stable branch in gitreview config

Change-Id: Ice96cf75dbdc8c0b3ef58d8eee1e8a5d7ff28518
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

Fix: ctf-writer: list of reserved keywords

The missing comma between "void" and "_Bool" causes the compiler to
treat it as one string ("void_Bool"), missing both "void" and "_Bool"
as real reserved keywords.

Signed-off-by: Bernhard Rosenkränzer <bero@lindev.ch>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I3da1b1f579d5fa1248501a8c2d9804ddbf467bc1
Reviewed-on: https://review.lttng.org/c/babeltrace/+/5964
Tested-by: jenkins <jenkins@lttng.org>

compiler warning cleanup: is_signed_type: compare -1 to 1

Comparing -1 to 0 triggers compiler warnings (gcc -Wtype-limits and
-Wbool-compare) and Coverity warning "Macro compares unsigned to 0".

Comparing -1 to 1 instead takes care of silencing those warnings while
keeping the same behavior.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I7d3a2d5a813838cef0e7b42d8c80ccf46f27ac62
Reviewed-on: https://review.lttng.org/c/babeltrace/+/5188
CI-Build: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Update working version to Babeltrace 2.0.5

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

Release: Babeltrace 2.0.4 "Amqui"

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

Fix: macro name for "get supported mip versions method" attribute descriptor

I tried to use BT_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD, I got:

    In file included from /home/simark/src/babeltrace/include/babeltrace2/babeltrace.h:67,
                     from /home/simark/src/babeltrace/src/cpp-common/bt2/plugin-dev.hpp:10,
                     from /home/simark/src/babeltrace/tests/cpp-common/plugin-dev/plugin.cpp:7:
    /home/simark/src/babeltrace/include/babeltrace2/plugin/plugin-dev.h:2214:91: error: ‘BT_PLUGIN_COMPONENT_CLASS_DESCRIPTOR_ATTRIBUTE_TYPE_GET_SUPPORTED_MIP_VERSIONS’ was not declared in this scope; did you mean ‘BT_PLUGIN_COMPONENT_CLASS_DESCRIPTOR_ATTRIBUTE_TYPE_GET_SUPPORTED_MIP_VERSIONS_METHOD’?
     2214 |  __BT_PLUGIN_COMPONENT_CLASS_DESCRIPTOR_ATTRIBUTE(sink_get_supported_mip_versions_method, BT_PLUGIN_COMPONENT_CLASS_DESCRIPTOR_ATTRIBUTE_TYPE_GET_SUPPORTED_MIP_VERSIONS, _plugin_id, _component_class_id, sink, _method)
          |                                                                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/simark/src/babeltrace/include/babeltrace2/plugin/plugin-dev.h:2641:11: note: in definition of macro ‘__BT_PLUGIN_COMPONENT_CLASS_DESCRIPTOR_ATTRIBUTE’
     2641 |   .type = _attr_type,     \
          |           ^~~~~~~~~~
    /home/simark/src/babeltrace/include/babeltrace2/plugin/plugin-dev.h:2224:2: note: in expansion of macro ‘BT_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD_WITH_ID’
     2224 |  BT_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD_WITH_ID(auto, _name, _method)
          |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/simark/src/babeltrace/src/cpp-common/bt2/plugin-dev.hpp:110:5: note: in expansion of macro ‘BT_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD’
      110 |     BT_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD(                              \
          |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/simark/src/babeltrace/tests/cpp-common/plugin-dev/plugin.cpp:19:1: note: in expansion of macro ‘BT_CPP_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD’
       19 | BT_CPP_PLUGIN_SINK_COMPONENT_CLASS_GET_SUPPORTED_MIP_VERSIONS_METHOD(the_sink, TheSink);
          | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think it should be

    BT_PLUGIN_COMPONENT_CLASS_DESCRIPTOR_ATTRIBUTE_TYPE_GET_SUPPORTED_MIP_VERSIONS_METHOD

instead of

    BT_PLUGIN_COMPONENT_CLASS_DESCRIPTOR_ATTRIBUTE_TYPE_GET_SUPPORTED_MIP_VERSIONS

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

Fix: configure: support Autoconf 2.70

This patch is stolen and adapted from lttng-tools' patch:

  https://git.lttng.org/?p=lttng-tools.git;a=commit;h=faa88ea855741f5c356d223011ff4b347576c7d2

The newly-released autoconf 2.70 introduces a number of breaking
changes [1] and is being rolled-out by some distros.

Amongst those changes, the AC_PROG_CC_STDC macro is marked as obsolete
and was merged into AC_PROG_CC, which we already use. On 2.70, this
results in a warning which we handle as an error.

A version check is added to invoke the AC_PROG_CC_STDC macro only when
running a pre-2.70 version of autoconf, fixing the issue.

The AC_PROG_LEX now takes an argument, and the argument-less version is
marked as obsolete. The macro is invoked with the `noyywrap` option, as
recommended in the documentation.

Also, the AX_PTHREAD macro makes use of the $as_echo built-in shell
variable which no longer exists in 2.70. A patch was submitted to the
GNU Autoconf archive in March, but there have been no signs of life
given since then [2].

As such, our local copy is updated to the latest version and the patch
(which looks fairly straight-forward / safe) is applied. This should
minimize changes once we go back to an "official" version of the macro.

Some issues with glib2 remain:

    configure.ac:264: warning: The macro `AC_TRY_RUN' is obsolete.
    configure.ac:264: You should run autoupdate.
    ./lib/autoconf/general.m4:2996: AC_TRY_RUN is expanded from...
    /usr/share/aclocal/glib-2.0.m4:11: AM_PATH_GLIB_2_0 is expanded from...
    configure.ac:264: the top level
    configure.ac:264: warning: The macro `AC_TRY_LINK' is obsolete.
    configure.ac:264: You should run autoupdate.
    ./lib/autoconf/general.m4:2919: AC_TRY_LINK is expanded from...
    /usr/share/aclocal/glib-2.0.m4:11: AM_PATH_GLIB_2_0 is expanded from...
    configure.ac:264: the top level

Those have been fixed upstream:

  https://gitlab.gnome.org/GNOME/glib/-/commit/6f26637e83727b05f865389937bb07c761c13c12

so it's always possible to get the modifications from there for local
development.

[1] https://lwn.net/Articles/839395/
[2] https://savannah.gnu.org/patch/?9906

Change-Id: I484b2caed1c7e89e100be76b7853099239397012
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>

port: add 'notext' keyword linker support

Check if the linker support the 'notext' keyword to allow relocations
against read-only segments. GNU ld defaults to notext but LLVM's ld does
not, both linkers support the keyword.

This is required for the plugins section symbols.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I952586447a837ce48711a218a2d03050ef3deb1a

port: fix compat/endian.h on FreeBSD

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I2f346213786392fc62ed1a815ccd367f162710ed

port: tests: Add sys/wait.h include for FreeBSD

Required for WIFEXITED and WEXITSTATUS.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I2a74762da3ffba58a27fecc3c0d85cc9007bd7c4

port: namespace align.h with BT_ prefix

ALIGN is defined in FreeBSD system includes with an incompatible
signature, namespace our internal version.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I2d7e24ebb1756b0e115118fa3f2e6ebc8595fea5

port: Add sys/param.h include to compat/limits.h for FreeBSD

Required for MAXHOSTNAMELEN.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I3adf11a260752cd6805802966be4db38f221d3ea

port: disable debug-info by default on FreeBSD

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Iea229bdcb00ae51a83fc7c5570415a5a7d264752

Fix: disable deprecation warnings for SWIG generated code

There is nothing we can do about deprecations in SWIG generated code so
silence this warning.

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

port: 'ls --ignore=' is a GNU extension

Use grep -v instead to filter README.adoc.

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

tests/lib/test_trace_ir_ref.c: rename user structure

Rename user structure to bt_user to avoid the following build failure
with uclibc:

test_trace_ir_ref.c:41:8: error: redefinition of 'struct user'
 struct user {
        ^
In file included from /home/naourr/work/instance-0/output-1/per-package/babeltrace2/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/procfs.h:33,
                 from /home/naourr/work/instance-0/output-1/per-package/babeltrace2/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/ucontext.h:25,
                 from /home/naourr/work/instance-0/output-1/per-package/babeltrace2/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/signal.h:329,
                 from /home/naourr/work/instance-0/output-1/per-package/babeltrace2/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/glib-2.0/glib/gbacktrace.h:36,
                 from /home/naourr/work/instance-0/output-1/per-package/babeltrace2/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/glib-2.0/glib.h:34,
                 from ../../src/common/assert.h:28,
                 from ../../src/lib/object.h:28,
                 from test_trace_ir_ref.c:25:
/home/naourr/work/instance-0/output-1/per-package/babeltrace2/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/user.h:48:8: note: originally defined here
 struct user
        ^~~~

Fixes:
 - http://autobuild.buildroot.org/results/e4229e2b9c892b419a9d2eaa6929b80ea62dd130

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Change-Id: I1a9d912545f781d61d6e3c62b31998285d2a237c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/4522
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 8009058387e16d70c065f8afb24953ed389c18a6)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/4540
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

Fix: sink.ctf.fs: fix logic of make_unique_stream_file_name

The logic in make_unique_stream_file_name is wrong.  It tries names as
long as the candidate exists _and_ is named "metadata".  The intent here
is that we keep trying names as long as the candidate name names an
already existing file _or_ is named "metadata".  So the && should be a
||.

The impact of this bug is that if two streams have the same name,
they'll write to the same file, with troubling consequences (see bug
1279 [1]).

Add a test where `sink.ctf.fs` writes a trace with two streams with the
same name, and one stream named "metadata".

[1] https://bugs.lttng.org/issues/1279

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

Fix: sink.ctf.fs: remove spurious directory level when using assume-single-trace

The behavior of `sink.ctf.fs` with the `assume-single-trace=true`
parameter does not match the documentation nor the comments in the code.
The man page says:

    If the assume-single-trace parameter is true, then the output trace
    path to use for the single input trace is the directory specified by
    the path parameter.

What I understand from this is that if you pass `path=/tmp/yo`, that
should produce the `/tmp/yo/metadata` file and the data files alongside
it.

The documentation on the `fs_sink_comp::assume_single_trace` says:

    /*
     * True if the component assumes that it will only write a
     * single CTF trace (which can contain one or more data
     * streams). This makes the component write the stream files
     * directly in the output directory (`output_dir_path` above).
     */
    bool assume_single_trace;

The `output_dir_path` would contain `/tmp/yo`, in the previous example,
so that confirms the previous assumption.

The actual behavior is that the sink puts the trace in an extra `trace`
directory, in `/tmp/yo/trace`.

We end up with the `trace` relative trace path (relative to the base
output directory) because `make_trace_path_rel` returns an empty string
when `assume_single_trace` is true and `sanitize_trace_path` replaces it
with `trace`.

When using `assume-single-trace=true`, we should not deal with a
relative trace path, as the trace is output directly in the base output
directory.  We also don't want to run the path in
`make_unique_trace_path`, as the trace should be output in the base
directory specified by the user, not another directory.  Anyway, if the
user specifies  an existing directory, `sink.ctf.fs` will initially
error out with:

    Single trace mode, but output path exists: output-path="/tmp/yo"

Although that's a TOCTOU bug, two babeltrace instances could both check
at the same time that the same output directory does not exist, and both
write in the same directory.  That would not be good.

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

Fix: bt2: _trim_docstring(): docstring can have 0 or 1 line

It is possible that a user component class's docstring has no lines or a
single one, for example:

    # no line
    class MySink(bt2._UserSinkComponent):
        """"""

        def _user_consume(self):
            pass

    # single line
    class MySink(bt2._UserSinkComponent):
        """The single line"""

        def _user_consume(self):
            pass

The previous version of _trim_docstring() expects this format:

    class MySink(bt2._UserSinkComponent):
        """
        My sink's description

        Dolore officia ex et aliquip eiusmod enim pariatur reprehenderit
        ad adipisicing non occaecat ullamco aliquip laborum duis
        proident ex duis.

        Irure commodo proident esse non pariatur in aute cillum id aute.
        """

        def _user_consume(self):
            pass

In _trim_docstring(), accept no lines or a single one.

Adding new tests to `test_component_class.py` to validate this
behaviour. The

    # fmt: off
    """
    """
    # fmt: on

docstring has off/on formatting markers as Black 20.8b1 transforms this
into the non-equivalent

    """"""

(which is another test now).

In addition, reformat Python files with Black v20.8b1, so that the
pylint CI job passes.

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

Fix: `ctf` plugin: use element FC's alignment as array/seq. FC alignment

Observed issue
==============
When reading some CTF trace with an empty array/sequence field,
Babeltrace 2 can fail.

More specifically, for the trace `tests/data/ctf-traces/succeed/array-align-elem`
(added by this patch):

The CLI's output is:

    07-21 14:00:24.636 73959 73959 E PLUGIN/CTF/MSG-ITER request_medium_bytes@msg-iter.c:535 [auto-disc-source-ctf-fs] User function returned EOF, but message iterator is in an unexpected state: state=DSCOPE_EVENT_PAYLOAD_CONTINUE, cur-packet-size=-1, cur=24, packet-cur=24, last-eh-at=16
    07-21 14:00:24.636 73959 73959 E PLUGIN/CTF/MSG-ITER read_dscope_continue_state@msg-iter.c:632 [auto-disc-source-ctf-fs] Cannot ensure that buffer has at least one byte: msg-addr=0x55d3b4e051f0, status=ERROR
    07-21 14:00:24.636 73959 73959 E PLUGIN/CTF/MSG-ITER ctf_msg_iter_get_next_message@msg-iter.c:2881 [auto-disc-source-ctf-fs] Cannot handle state: msg-it-addr=0x55d3b4e051f0, state=DSCOPE_EVENT_PAYLOAD_CONTINUE
    07-21 14:00:24.636 73959 73959 E PLUGIN/SRC.CTF.FS ctf_fs_iterator_next_one@fs.c:90 [auto-disc-source-ctf-fs] Failed to get next message from CTF message iterator.
    07-21 14:00:24.636 73959 73959 W LIB/MSG-ITER bt_message_iterator_next@iterator.c:865 Component input port message iterator's "next" method failed: iter-addr=0x55d3b4e05000, iter-upstream-comp-name="auto-disc-source-ctf-fs", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE, iter-upstream-comp-class-name="fs", iter-upstream-comp-class-partial-descr="Read CTF traces from the file sy", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="array-align-elem | 0 | array-align-elem/stream", status=ERROR
    07-21 14:00:24.636 73959 73959 E PLUGIN/FLT.UTILS.MUXER muxer_upstream_msg_iter_next@muxer.c:446 [muxer] Upstream iterator's next method returned an error: status=ERROR
    07-21 14:00:24.636 73959 73959 E PLUGIN/FLT.UTILS.MUXER validate_muxer_upstream_msg_iters@muxer.c:989 [muxer] Cannot validate muxer's upstream message iterator wrapper: muxer-msg-iter-addr=0x55d3b4dcb830, muxer-upstream-msg-iter-wrap-addr=0x55d3b4e055c0
    ev: { a = 1, b = [ ], c = 2 }
    07-21 14:00:24.636 73959 73959 E PLUGIN/FLT.UTILS.MUXER muxer_msg_iter_next@muxer.c:1417 [muxer] Cannot get next message: comp-addr=0x55d3b4dcae70, muxer-comp-addr=0x55d3b4dcaef0, muxer-msg-iter-addr=0x55d3b4dcb830, msg-iter-addr=0x55d3b4dcb750, status=ERROR
    07-21 14:00:24.636 73959 73959 W LIB/MSG-ITER bt_message_iterator_next@iterator.c:865 Component input port message iterator's "next" method failed: iter-addr=0x55d3b4dcb750, iter-upstream-comp-name="muxer", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=FILTER, iter-upstream-comp-class-name="muxer", iter-upstream-comp-class-partial-descr="Sort messages from multiple inpu", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
    07-21 14:00:24.636 73959 73959 W LIB/GRAPH consume_graph_sink@graph.c:462 Component's "consume" method failed: status=ERROR, comp-addr=0x55d3b4dcb070, comp-name="pretty", comp-log-level=WARNING, comp-class-type=SINK, comp-class-name="pretty", comp-class-partial-descr="Pretty-print messages (`text` fo", comp-class-is-frozen=1, comp-class-so-handle-addr=0x55d3b4dc7c50, comp-class-so-handle-path="/home/eepp/dev/babeltrace/install/lib/babeltrace2/plugins/babeltrace-plugin-text.la", comp-input-port-count=1, comp-output-port-count=0
    07-21 14:00:24.636 73959 73959 E CLI cmd_run@babeltrace2.c:2529 Graph failed to complete successfully

    ERROR:    [Babeltrace CLI] (babeltrace2.c:2529)
      Graph failed to complete successfully
    CAUSED BY [libbabeltrace2] (graph.c:462)
      Component's "consume" method failed: status=ERROR, comp-addr=0x55d3b4dcb070, comp-name="pretty", comp-log-level=WARNING, comp-class-type=SINK,
      comp-class-name="pretty", comp-class-partial-descr="Pretty-print messages (`text` fo", comp-class-is-frozen=1, comp-class-so-handle-addr=0x55d3b4dc7c50,
      comp-class-so-handle-path="/home/eepp/dev/babeltrace/install/lib/babeltrace2/plugins/babeltrace-plugin-text.la", comp-input-port-count=1,
      comp-output-port-count=0
    CAUSED BY [libbabeltrace2] (iterator.c:865)
      Component input port message iterator's "next" method failed: iter-addr=0x55d3b4dcb750, iter-upstream-comp-name="muxer",
      iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=FILTER, iter-upstream-comp-class-name="muxer",
      iter-upstream-comp-class-partial-descr="Sort messages from multiple inpu", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
    CAUSED BY [muxer: 'filter.utils.muxer'] (muxer.c:1417)
      Cannot get next message: comp-addr=0x55d3b4dcae70, muxer-comp-addr=0x55d3b4dcaef0, muxer-msg-iter-addr=0x55d3b4dcb830, msg-iter-addr=0x55d3b4dcb750,
      status=ERROR
    CAUSED BY [muxer: 'filter.utils.muxer'] (muxer.c:989)
      Cannot validate muxer's upstream message iterator wrapper: muxer-msg-iter-addr=0x55d3b4dcb830, muxer-upstream-msg-iter-wrap-addr=0x55d3b4e055c0
    CAUSED BY [muxer: 'filter.utils.muxer'] (muxer.c:446)
      Upstream iterator's next method returned an error: status=ERROR
    CAUSED BY [libbabeltrace2] (iterator.c:865)
      Component input port message iterator's "next" method failed: iter-addr=0x55d3b4e05000, iter-upstream-c

Cause
=====
The internal CTF IR array and sequence field classes do not have an
alignment which is equal to their element FC's alignment, although
CTF 1.8.3 requires it [1]:

> Arrays are always aligned on their element alignment requirement.

Solution
========
In `bfcr.c`, align_class_state() is already called for array/sequence
fields.

Add a CTF IR trace class visitor to set any array/sequence FC's
alignment to its element FC's alignment, recursively (postorder).

Also update, postorder, structure FC alignments since some of the
alignments of the field types of their members can change.

Note
====
This patch adds two minimalist CTF traces to test the fix as well as two
new corresponding tests in
`tests/plugins/src.ctf.fs/succeed/test_succeed`:

`array-align-elem`:
    Metadata:

        struct {
            integer { size = 8; } a;
            integer { size = 8; align = 16; } b[0];
            integer { size = 8; } c;
        };

    Taking the aligment of `b` into account, there's one byte of padding
    between `a` and `c`:

        a # c
          ^---- alignment of `b`

`struct-array-align-elem`:
    Metadata:

        struct {
            integer { size = 8; } x;
            struct {
                integer { size = 8; } a;
                integer { size = 8; align = 32; } b[0];
            } y;
            integer { size = 8; } z;
        };

    Taking the alignment of `y.b` into account, the `y` structure itself
    is 32-bit-aligned, making the outer structure also 32-bit-aligned.
    Therefore, there are three bytes of padding between `x` and `a`, and
    three other bytes of padding between `a` and `z`:

        x # # # a # # # z
          ^       ^-------- alignment of `b`
          '---------------- alignment of `y`

References
==========
[1]: https://diamon.org/ctf/v1.8.3/#spec4.2.3

Fixes: https://bugs.lttng.org/issues/1276
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I06b4fbeda9ffd5b87b4964dd567027d0bfd5e9c7
Reviewed-on: https://review.lttng.org/c/babeltrace/+/4056

Fix: source.ctf.lttng-live: muxing failure on clear (unit conversion)

This commit is a follow-up fix for 8ec4d5ff (see original message).
The original fix included a bogus comparison of:
  `stream_iter->last_inactivity_ts > curr_msg_ts_ns`

While the idea behind the fix is valid, this statement compares
nanoseconds since Unix Epoch (former) to clock cycles (latter).

A conversion of the `last_inactivity_ts` to nanoseconds since Unix epoch
is performed using the stream's default clock class allowing a
comparison in a common time base to take place.

The diff looks more intimidating than it really is as it shifts the
indentation of a lot of code at once. This is because we only want to
perform the timestamp conversion when necessary (very rarely) on this
fairly hot path.

Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ibdc365fec4685da88ae141383d5e5ef0af169a87

Fix: src.ctf.lttng-live: incomplete metadata packet is an error

Observed issue
==============

While investigating the issue described in [1], I noticed that
babeltrace2 falls into a retry loop when the src.ctf.lttng-live
component encounters unparseable metadata.

The src.ctf.lttng-live reports parsing errors on every subsequent
reception of a metadata packet. The relay daemon eventually sends
binary data which fails to be decoded, ending the graph's execution
with a binary decoding error, which is not the "real" issue.

Cause
=====

Due to a (now fixed) bug in LTTng [1], unparseable (incomplete)
metadata can be made visible to live clients. This bug fix doesn't
involve the clients; it resulted in an illegal state in the lttng-live
protocol.

When the relay daemon notifies the live client that new metadata is
available, lttng_live_metadata_update() receives all the metadata made
available by the relay daemon in a memory stream and then uses the
ctf_metadata_decoder to append the new content to the existing trace
class.

However, if the decoder returns
`CTF_METADATA_DECODER_STATUS_INCOMPLETE`,
`LTTNG_LIVE_ITERATOR_STATUS_AGAIN` is returned to the caller,
resulting in the graph retrying to invoke the live iterator's `next`
method until another error eventually prevents the successful
completion of the graph.

I am assuming that the use of the `AGAIN` status code may have been a
failed attempt at fixing [1] in the live component rather than
adressing the underlying problem.

Solution
========

To my knowledge there are no provisions made for incomplete metadata
in the lttng-live protocol as of the current version. This may have
been done in anticipation of a future change (?), but it currently
obscures the error reported when a corrupted/incomplete/unparseable
metadata packet is received by the src.ctf.lttng-live component.

The current approach doesn't work anyhow as
lttng_live_metadata_update() creates a "fresh" memory stream on each
invocation. If the intention was to accumulate partial metadata until
it can be successfully parsed, the accumulated metadata would have to
be preserved from one invocation to the next.

The conversion of the status code from `INCOMPLETE` to `AGAIN` is
removed to fail immediately during the current invocation of the
iterator's `next` method.

Drawbacks
=========

None.

References
==========

[1] https://github.com/lttng/lttng-tools/commit/f5ba75b4f0c0b44092c76bc931b25b24a2e62718

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

Fix: source.ctf.lttng-live: muxing failure on clear

Observed issue
==============

The lttng-tools port builds regularly fail on the CI with the following
error:

```
05-28 16:13:52.864 11219 11219 E PLUGIN/SRC.CTF.LTTNG-LIVE next_stream_iterator_for_trace@lttng-live.c:1067 [lttng-live] Message's timestamp is less than lttng-live's message iterator's last returned timestamp: lttng-live-msg-iter-addr=0xd810220dd30, ts=1590696831733594090, last-msg-ts=1590696832514058899
05-28 16:13:52.864 11219 11219 E PLUGIN/SRC.CTF.LTTNG-LIVE lttng_live_msg_iter_next@lttng-live.c:1502 [lttng-live] Error preparing the next batch of messages: live-iter-status=LTTNG_LIVE_ITERATOR_STATUS_ERROR
05-28 16:13:52.864 11219 11219 W LIB/MSG-ITER bt_message_iterator_next@iterator.c:868 Component input port message iterator's "next" method failed: iter-addr=0xd810221c7c0, iter-upstream-comp-name="lttng-live", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE, iter-upstream-comp-class-name="lttng-live", iter-upstream-comp-class-partial-descr="Connect to an LTTng relay daemon", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
05-28 16:13:52.864 11219 11219 W LIB/GRAPH consume_graph_sink@graph.c:466 Component's "consume" method failed: status=ERROR, comp-addr=0xd81022373a0, comp-name="sink.text.details", comp-log-level=WARNING, comp-class-type=SINK, comp-class-name="details", comp-class-partial-descr="Print messages with details.", comp-class-is-frozen=0, comp-class-so-handle-addr=0xd8102233ca0, comp-class-so-handle-path="/tmp/debug_jgalar/build/usr/lib/babeltrace2/plugins/babeltrace-plugin-text.so", comp-input-port-count=1, comp-output-port-count=0
05-28 16:13:52.865 11219 11219 E CLI cmd_run@babeltrace2.c:2530 Graph failed to complete successfully

ERROR:    [Babeltrace CLI] (babeltrace2.c:2530)
  Graph failed to complete successfully
CAUSED BY [libbabeltrace2] (graph.c:466)
  Component's "consume" method failed: status=ERROR, comp-addr=0xd81022373a0,
  comp-name="sink.text.details", comp-log-level=WARNING, comp-class-type=SINK,
  comp-class-name="details", comp-class-partial-descr="Print messages with
  details.", comp-class-is-frozen=0, comp-class-so-handle-addr=0xd8102233ca0,
  comp-class-so-handle-path="/tmp/debug_jgalar/build/usr/lib/babeltrace2/plugins/babeltrace-plugin-text.so",
  comp-input-port-count=1, comp-output-port-count=0
CAUSED BY [libbabeltrace2] (iterator.c:868)
  Component input port message iterator's "next" method failed:
  iter-addr=0xd810221c7c0, iter-upstream-comp-name="lttng-live",
  iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE,
  iter-upstream-comp-class-name="lttng-live",
  iter-upstream-comp-class-partial-descr="Connect to an LTTng relay daemon",
  iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
CAUSED BY [lttng-live: 'source.ctf.lttng-live'] (lttng-live.c:1502)
  Error preparing the next batch of messages:
  live-iter-status=LTTNG_LIVE_ITERATOR_STATUS_ERROR
CAUSED BY [lttng-live: 'source.ctf.lttng-live'] (lttng-live.c:1067)
  Message's timestamp is less than lttng-live's message iterator's last returned
  timestamp: lttng-live-msg-iter-addr=0xd810220dd30, ts=1590696831733594090,
  last-msg-ts=1590696832514058899
```

The test that ends up with this error performs a session `clear`
while tracing an application as part of a "live" session.

Cause
=====

Given the following trace,

| pkt seq:0 |<-------discarded packets------>| pkt seq:8 |
0          20                                121       140

a CTF source is expected to introduce a "Discarded Packets" message
between packets 0 and 8. The begin and end timestamps of such a message
are synthesized from the timestamps of the last known packet (seq:0)
and the newly decoded packet (seq:8).

For instance, here the Discarded Packets message would have the bounds
[pkt0.end_ts, pkt8.begin_ts].

In the context of a live source, the tracer could report an inactivity
period during the interval of the "Discarded packets" message.

Those live protocol messages eventually translate into an "Iterator
Inactivity" message with a timestamp set at the end of the inactivity
period.

If the tracer reports an inactivity period that ends at a point
between pkt0 and pkt8 (resulting in an "Iterator Inactivity" message),
the live source will send a "Discarded Packets" message that starts
before the preceding "Iterator Inactivity" message, breaking the
monotonicity constraint of the graph.

This happens regularly when `clear` is used on an LTTng live session as
it effectively discards packets, something that would otherwise not
happen (before LTTng 2.12) as most users set their tracing channels in
"discard" mode (the default for that session type).

However, the same problem as described above applies to "Discarded
Events" messages and could occur with older LTTng versions.

Solution
========

"Discarded Events" and Discarded Packets" messages are intercepted
in the lttng-live source's "muxer" and are _adjusted_ so that
they honor the monotonicity guarantee of the graph.

In effect, whenever such a message is seen to have a begin timestamp
that is _before_ the last inactivity timestamp, its begin timestamp
is adjusted to the last inactivity timestamp's value.

From a correctness standpoint, this is okay. If the tracer notified the
relay daemon of an inactivity period on a stream, we can rely on the
fact that no data was produced during that time to affirm that no
packets where lost during that time either.

A test reproducing the "Discarded Packets" scenatio described in
this message is added in a follow-up patch.

Known drawbacks
===============

None.

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

Fix: source.ctf.fs: 0-length packet index length causes SIGFPE

A corrupted index can present a 0-length packet index length
which will result in a division by 0 when computing the index
entry count.

Program terminated with signal SIGFPE, Arithmetic exception.
 #0  0x00007f6ecbd44978 in build_index_from_idx_file (ds_file=0x561ade51ca00, file_info=0x561ade51d000,
    msg_iter=0x561ade51cd00) at data-stream-file.c:640
640 file_entry_count = (filesize - sizeof(*header)) / file_index_entry_size;

The index packet length is checked against the smallest valid size:
the size of an index entry as of the 1.0 CTF index version.

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

Update working version to Babeltrace 2.0.4

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

Release: Babeltrace 2.0.3 "Amqui"

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

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

Running

  babeltrace2 --debug /some/trace

... results in the following crash:

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

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

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

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

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

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

The assertion failure we get is:

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

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

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

Add initial Python bindings documentation

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

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

Changes:

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

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

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

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

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

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

Backported from ba64dfcccb1f1bd7a259dc5d563ba422b8375582

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

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

Fix: bt2: read properties on _DiscardedEventsMessage

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

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

Results in:

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

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

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

tests: add tests for discarded events/packets creation

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

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

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

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

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

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

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

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

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

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

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

Change-Id: I9b113d2e335d529599cb9197c39c8675915508e5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3393
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit 6adf99d540b2d239fc49bb64934becf410812c39)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3363
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>

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

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

Change-Id: I82b2719316ad00ffd9d9c14b86b8890b98130669
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3383
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit c7f21c12d5cec35f3e48630cf603207748409847)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3362
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

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

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

Change-Id: I2b47c6ce7c6099a6db68c4da108d7c0886c7177e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3384
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
(cherry picked from commit c16fb81a23dcfa6ab8331efe1c98a86e4444040d)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3361
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

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

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

Sorry.

Change-Id: I11cc739c126131560ba31d2a1f3f01b7e961a837
Reviewed-on: https://review.lttng.org/c/babeltrace/+/3354
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>

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

Initialize the pointer other_entry to silence this warning:

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

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

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

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

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

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

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

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

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

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

* The enumeration field class is not modified.

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

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

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

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

Here's an example to generate such paragraphs:

    @param some_param
        @parblock
        Normal paragraph.

        Bold paragraph.

        Also bold.
        @endparblock

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

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

Update working version to Babeltrace 2.0.3

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

Release: Babeltrace 2.0.2 "Amqui"

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

common: cast arguments to character classification functions to unsigned char

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

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

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

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

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

The Linux man page for isprint also mentions it:

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

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

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

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

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

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

gcc 4.8 shows this warning:

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

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

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

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

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

Fix: configure.ac: silently accepting invalid Python configuration

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

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

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

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

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

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

Fixes #1240

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Change them to use BT_CLI_LOGE_APPEND_CAUSE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fix: correct typo in README

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

Update working version to Babeltrace 2.0.2

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