973f89a...
by
Michael Jeanson <email address hidden>
tests: return the proper TAP exit code
The C TAP library provides the 'exit_status()' function that will return
the proper exit code according to the number of tests that succeeded or
failed.
Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Jérémie Galarneau <email address hidden>
Change-Id: Ia76ed7d1510bb23bf3848f85ac9022c66e752311
(cherry picked from commit d6641c890cd38d0c43a84fd54ccf3c10de88a56b)
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12475
Reviewed-by: Philippe Proulx <email address hidden>
CI-Build: Simon Marchi <email address hidden>
Tested-by: jenkins <email address hidden>
CCLD test_dwarf
In function 'test_bt_dwarf',
inlined from 'main' at /home/smarchi/src/babeltrace/tests/plugins/flt.lttng-utils.debug-info/test_dwarf.c:163:2:
/home/smarchi/src/babeltrace/tests/plugins/flt.lttng-utils.debug-info/test_dwarf.c:136:9: error: 'tag' may be used uninitialized [-Werror=maybe-uninitialized]
136 | ok(tag == DW_TAG_typedef, "bt_dwarf_die_get_tag - correct tag value");
| ^
/home/smarchi/src/babeltrace/tests/plugins/flt.lttng-utils.debug-info/test_dwarf.c: In function 'main':
/home/smarchi/src/babeltrace/tests/plugins/flt.lttng-utils.debug-info/test_dwarf.c:79:22: note: 'tag' was declared here
79 | int fd, ret, tag;
| ^
Indeed, `tag` is not set if `bt_dwarf_die_get_tag()` fails, and I
suppose that LTO is able to "see" through the function call, despite the
implementation being in another compilation unit.
Fix this by initializing `tag` to an invalid DIE tag value.
For some reason, I only see this error on the stable-2.0 branch, not on
master. But I think it wouldn't hurt to merge this patch to both master
and stable-2.0.
I caught this when trying to build the 2.0.6 release as an Arch package,
using the official PKGBUILD as a base.
f84425c...
by
=?utf-8?q?J=C3=A9r=C3=A9mie_Galarneau?= <email address hidden>
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.
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:
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`
