Simon Marchi [Tue, 19 Nov 2019 17:05:24 +0000 (12:05 -0500)]
lib: add comment to bt_plugin_so_create_all_from_static
This symbol would normally not be exposed, but it is used from the
Python plugin provider, which is conceptually part of libbabeltrace2,
but implemented as a separate shared library. Add a comment to explain
that.
Change-Id: Ie6e14edc30489ab6f8c6aadba32a3ceb9726e3b0
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2406
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Tue, 19 Nov 2019 17:04:25 +0000 (12:04 -0500)]
lib: make bt_object_pool symbols hidden
bt_object_pool_initialize and bt_object_pool_finalize are not supposed
to be exposed by the shared library, so make them hidden.
Change-Id: I072b692f627f4b66b4e5907eeb228d6327d3d70e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2405
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Tue, 19 Nov 2019 17:01:30 +0000 (12:01 -0500)]
lib: make symbols in prio-head hidden
These are not supposed to be exposed by the shared library, so make them
hidden.
Change-Id: If1f728f1b536d1be1e38dfff8ca2aba8d4bd1868
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2404
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Tue, 22 Oct 2019 21:55:25 +0000 (17:55 -0400)]
tests: add CLI query tests
Add a few simple tests for the query CLI command, using a custom Python
component class.
Change-Id: Ic2b2d3f9f5e0f460f596bd1e4403c250ec2daad5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2245
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Tue, 19 Nov 2019 16:22:42 +0000 (11:22 -0500)]
param-parse: use g_string_append_c instead of g_string_append_printf
... to append a single character.
I did some tests to evaluate the performance impact of this patch, in
terms of number of instructions. I ran the following command line 20
times and computed the average and standard deviation of the number of
execution instructions.
$ libtool --mode=execute perf stat -e instructions:u ./src/cli/babeltrace2 query -p '
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=2,' src.ctf.fs yo
average stdev
Without this patch:
1079692 51
With this patch:
1039197 51
This represents a reduction of 3.75% in the number of executed
instructions.
Change-Id: I8109d42d0fa357e47642132a2f3b9581d72bcefa
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2403
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Wed, 13 Nov 2019 22:00:08 +0000 (17:00 -0500)]
lib: remove bt_packet_context_field API
Change-Id: I357daa5915140882dab47acb70570178fb767db8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2390
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 15 Nov 2019 19:39:59 +0000 (14:39 -0500)]
ctf: make msg-iter not use bt_packet_context_field
The bt_packet_context_field API exists so that the CTF message iterator
could store packet context fields in contexts where it doesn't create
trace-ir objects. For example, in add_ds_file_to_ds_file_group, we use
a message iterator just to sniff the properties of the first packet of a
data stream file.
However, the CTF message iterator doesn't really use it anymore, it just
stores the relevant properties in fields of the ctf_msg_iter structure
and transfers them to the caller in ctf_msg_iter_get_packet_properties.
So the bt_packet_context_field API no longer has a reason to be. This
patch makes msg-iter stop using it, so it can be removed.
Currently, the packet_context_field is created when needed, which is
just before reading the packet context, in
read_packet_context_begin_state. A bt_packet is later created in
create_msg_packet_beginning, and the packet_context_field is moved into
the bt_packet.
If we want to get rid of the packet_context_field, it means we need to
create the bt_packet earlier (if not in dry_run mode), so it is
available in read_packet_context_begin_state, so that the packet context
fields are read directly into the bt_packet. And to create the
bt_packet, the bt_stream needs to be available. The bt_stream is
currently created just before sending the stream beginning message, in
ctf_msg_iter_get_next_message.
So this patch moves the creation of the bt_stream and bt_packet as early
as possible, just after we have read the packet header, in
after_packet_header_state. In read_packet_context_begin_state, we can
then find the packet already created in msg_iter->packet.
This change made it necessary to set the dry run flag on the CTF message
iterator in add_ds_file_to_ds_file_group (which should have probably
already been there anyway). This iterator is used to read the packet
context, which, previously, didn't trigger the creation of the bt_stream
and bt_packet. But now that we create those earlier, it is necessary
to set the flag to avoid them being created.
It was also needed to change the check in after_packet_context_state to
know whether we are at the first packet, and therefore need to emit a
stream beginning message, or if we are at a subsequent packet, and
therefore need to skip that step. We would previously check whether the
msg_it->stream field was set, but this is now always true given that we
set the stream earlier. The only way that I found to fix that is to add
the boolean flag emit_stream_beginning_message in the message iterator.
Change-Id: Ib907480727d00d51aabd89986375d533ad385c96
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2393
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 18 Nov 2019 19:37:33 +0000 (14:37 -0500)]
ctf: remove ctf_msg_iter::set_stream
This field is set but not used.
Change-Id: Ibca38c8421b8d734462077a19da1726a817f3cb6
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2401
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Tue, 19 Nov 2019 21:11:44 +0000 (16:11 -0500)]
src.ctf.fs: fix typo in comment
Change-Id: I2a3ee8d019b7dfb966aba3a1e9a5d7fc375eb9e7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2413
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Mon, 18 Nov 2019 21:45:46 +0000 (16:45 -0500)]
lib: mark bt_common_assert_failed as hidden
I noticed that the bt_common_assert_failed symbol was exported. This is
not desirable, as it's not part of the API, so mark it with BT_HIDDEN.
As a consequence, a bunch of small tests that use BT_ASSERT miss this
symbol, as they were getting it from libbabeltrace2. Make them depend
on libbabeltrace2-common (and libbabeltrace2-logging) directly to fix
that.
Change-Id: I25ab69e7df08f508389f5c9c3db5571ee7b06d7b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2402
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Jérémie Galarneau [Fri, 15 Nov 2019 23:07:51 +0000 (18:07 -0500)]
Update version to v2.0.0-rc4
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Idfe7be3fc2eb22bf1e526d6fe6aeb0ce0f5aae88
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2397
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 15 Nov 2019 22:09:05 +0000 (17:09 -0500)]
babeltrace2-source.ctf.fs(7): document the overlapping snapshot feature
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I482a366679f65a577cb7081ce46736ab484858c3
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2395
Simon Marchi [Fri, 15 Nov 2019 18:28:02 +0000 (13:28 -0500)]
Revert "Notes de relâche du troisième candidat de relâche"
This reverts commit
98403f26955dc80727dc34974ba1e98d0ead61d1.
Simon Marchi [Thu, 14 Nov 2019 22:27:14 +0000 (17:27 -0500)]
Notes de relâche du troisième candidat de relâche
Change-Id: I8d3811ed4fc3196434ee2aebc1af6c542df53824
Simon Marchi [Tue, 12 Nov 2019 20:26:42 +0000 (15:26 -0500)]
ctf: remove ctf_msg_iter_set_emit_stream_{beginning,end}_message functions
These functions are now unnecessary. Before the previous patch
"src.ctf.fs: add and use medops to iterate on a ds_file_group using the
index", the src.ctf.fs component used ctf_msg_iter in such a way that
the iterator would process complete data stream files one after the
other, and was reset between each file. When starting a data stream
file, the iterator needed to know whether it was the first data stream
file for a given stream, and therefore if it should emit the stream
beginning message. Conversely, it needed to know if the data stream
file was the last one for the stream, and therefore if it needed to emit
the stream end message.
With the new ctf_fs_ds_group_medops, the ctf_msg_iter reads entire
streams, even if they are spread over multiple data stream files. We
therefore don't need to say whether a particular iterator run is the
beginning or end of a stream, it always is.
With lttng-live, the iterator also always does a single run so always
needs to emit the stream messages.
This patch also removes the related fields in ctf_msg_iter, as well as
the related states in the state machine.
The only non-obvious thing is: what to do with the call to
set_current_stream in check_emit_msg_stream_beginning_state. This is
the moment where the message iterator asks the medium to provide the
bt_stream instance for the given stream class and stream instance id.
For now, I moved it to just before we need it the first time, which is
when sending the stream beginning message. This is probably temporary
anyway, as it is planned that we will be able to just pass the bt_stream
when creating the ctf_msg_iter.
Change-Id: I275d4631ff11612abb46c73312bf133753ae4971
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 14 Nov 2019 21:32:34 +0000 (16:32 -0500)]
src.ctf.fs: use ctf_fs_ds_index_destroy to free index
The function ctf_fs_ds_file_group_destroy frees the ctf_fs_ds_index
structure and its content by hand. Replace that with a call to
ctf_fs_ds_index_destroy, which is meant for that.
Change-Id: I186b1da9ec63cbdfa7ef7966d1e0e9802827e4f7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Wed, 6 Nov 2019 21:01:24 +0000 (16:01 -0500)]
src.ctf.fs: add and use medops to iterate on a ds_file_group using the index
This patch solves the problem of reading multiple snapshots of the same
tracing session taken quickly. Taking the snapshots quickly enough can
cause them to overlap, in which case some complete / identical packets
will be found in different snapshots.
As an example, imagine we have three snapshots, and packets labeled from
A to G belonging the same stream instance in all snapshots. We could
have the following sequence of packets in each snapshot:
- snapshot 1: A B C D
- snapshot 2: C D E F
- snapshot 3: D E F G
Babeltrace 1 reads these three snapshots successfully. In fact, it just
considers them as three different traces, so it will order events
individually. As a result, events from packet D will be present three
times in the output. So while it works (as in Babeltrace exits with
status 0), it's probably not what a user would want.
Babeltrace 2 (before this patch) hits the following assert, which
validates that messages produced by iterators never go back in time:
11-11 15:13:23.874 8329 8329 F LIB/MSG-ITER call_iterator_next_method@iterator.c:872 Babeltrace 2 library postcondition not satisfied; error is:
11-11 15:13:23.874 8329 8329 F LIB/MSG-ITER call_iterator_next_method@iterator.c:872 Clock snapshots are not monotonic
11-11 15:13:23.874 8329 8329 F LIB/MSG-ITER call_iterator_next_method@iterator.c:872 Aborting...
This is because Babeltrace 2 groups all CTF traces sharing the same UUID
(which is the case for our three snapshots) and gives them to the same
src.ctf.fs component to read. The component groups data stream files
from the various snapshots by stream instance id, and sorts them
according to the timestamp of their first event. It then reads them
sequentially, from end to end, assuming that the start of the second
data stream file is after the end of the first data stream file. Using
our example above, the src.ctf.fs component would therefore try to read
packets in this order:
A B C D C D E F D E F G
^
`- ouch!
In this case, we want to read all packets exactly once, in the right
order.
The solution brought by this patch is to iterate on the packets by
following the index, instead of reading all data files from end to end.
Index entries were already de-duplicated by commit
ctf: de-duplicate index entries
So the index already refers to a single instance of each packet. We can
therefore use it as a playlist of the packets to read.
The change mainly revolves around adding a new kind of CTF message
iterator medium operations, called ctf_fs_ds_group_medops. Instead of
the medium being a single data stream file, like in
ctf_fs_ds_file_medops, this new medium is conceptually the sequence of
all packets described by the index of a ctf_fs_ds_group, possibly spread
out in different data stream files.
A new optional medium operation called `switch_packet` is added. When
the CTF message iterator is done reading a packet, it calls this method,
indicating to the medium that it is at the frontier of two packets. If
the medium is aware of the packets (like ctf_fs_ds_group_medops is) and
knows that the following packet is not contiguous with the previous
packet, it can reposition its "read head" at the right place (open the
new file, go to the right offset). Immediatly after calling
`switch_packet`, the message iterator calls the `request_bytes` method,
which allows the medium to return a buffer containing the bytes of the
next packet.
When the packet-aware medium has its `switch_packet` method called but
there are no more packets to read, it returns
CTF_MSG_ITER_MEDIUM_STATUS_EOF. That brings the message iterator in the
STATE_CHECK_EMIT_MSG_STREAM_END state, which will close the stream.
If the `switch_packet` method is not provided by the medium, the message
iterator just continues, assuming that the bytes of the next packet are
contiguous with those of the previous packet.
The ctf_fs_ds_file_medops medium operations are still necessary for
reading individual ctf_fs_ds_files, when initializing src.ctf.fs
components. This is needed when building the index from a stream or for
applying tracer fixups.
This simplifies a little bit the interaction between the src.ctf.fs
iterator and the ctf_msg_iter. Previously, we would read each data
stream file until the message iterator returned EOF. If it wasn't the
last data stream file, we would reset the iterator to read the next data
stream file. Functions
ctf_msg_iter_set_emit_stream_{beginning,end}_message were necessary to
indicate to the message iterator whether to send the stream beginning or
end messages, because it had otherwise no idea of whether the data
stream file it is reading is the first one or last one. The function
ctf_msg_iter_set_medops_data was necessary to swap the data of the
ctf_fs_ds_file_medops to point to the new data stream file.
With the ctf_fs_ds_group_medops, the CTF message iterator only returns
EOF when the stream is done. The data passed to the
ctf_fs_ds_group_medops has everything it needs to go through all the
packets, so it doesn't need to change.
Change-Id: I72f6d1e09b87414fb83f68cb57abb1f2dc61b439
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Mon, 11 Nov 2019 21:55:42 +0000 (16:55 -0500)]
tests: make test_trimmer use bt_cli
... instead of launching babeltrace2.exe by hand. This makes the
testsuite print the executed command lines, and is therefore easier to
debug.
Change-Id: I82f3984e749b8e6aff38b529ed462373eabd24dc
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 22:05:50 +0000 (17:05 -0500)]
src.ctf.fs: factor out "ds_file_mmap" from "ds_file_mmap_next"
Currently, the logic to mmap a region of a ds_file is contained in
ds_file_mmap_next. ds_file_mmap_next is also responsible for mapping
the region immediately following the currently mapped region, if there
is a currently mapped region.
I find this double responsibility a bit confusing, especially where
ds_file_mmap_next is used in medop_seek.
This patch extracts a portion of ds_file_mmap_next to a new function
ds_file_mmap, whose job is to ensure a file offset is mapped, and to do
the needful if it isn't.
Change-Id: Ia19725d28cf9c24084a52d16c7a88f30b32ff694
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 22:44:59 +0000 (17:44 -0500)]
src.ctf.fs: remove ctf_fs_ds_file::end_reached field
It is set, but not used for anything, so remove it.
Change-Id: I502fa683e6ab94a54959918978c4ffd683c5768e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 22:21:47 +0000 (17:21 -0500)]
ctf: assert that request_sz in medium ops request_bytes is greater than 0
There's a check in medop_request_bytes to return OK if the passed
request_sz is 0. I don't think that can ever happen, since that
request_sz comes from the max_request_sz parameter when the iterator is
created. It wouldn't make sense to pass 0.
Change-Id: Ia2c8fb6e56195bcab607c39e366c6b58b3411f8b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 21:00:57 +0000 (16:00 -0500)]
ctf: make ctf_msg_iter_seek assert that the seek callback is not NULL
There should be no reason to call ctf_msg_iter_seek if there is no seek
callback. It's the user of the ctf_msg_iter who passes medium
operations (at creation time), so it should be aware if there is a seek
callback or not.
This allows removing the UNSUPPORTED values in enum ctf_msg_iter_status
and enum ctf_msg_iter_medium_status.
Change-Id: Ic3591b1e909c7cf0e12d18f40b921a180cf344c8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 20:22:39 +0000 (15:22 -0500)]
ctf: assert that msg iter and medium seek offset is valid
I don't think there is ever a valid situation for `offset` to have an
invalid value in ctf_msg_iter_seek or medop_seek. If the user of the
iterator (e.g. fs.c) thinks it's cool enough to seek, it should know
about the underlying medium it used to create the msg iter and make sure
not to seek at an invalid position.
This allows removing the INVAL values in enum ctf_msg_iter_medium_status
and enum ctf_msg_iter_status.
Change-Id: I19d48fe751aebf21e60c5cbc16127919a5fa72f3
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 20:18:01 +0000 (15:18 -0500)]
src.ctf.fs: remove ctf_msg_iter_seek_whence parameter to medium ops seek
It is useless, as there is a single value. If we ever really need to
specify if the given offset is absolute or relative, we can add back a
parameter, as this is an internal API. In the mean time, it's just an
annoyance.
Change-Id: I3eba79f51d9d5aee82d3bed6ce736459f8dbffa3
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 20:13:20 +0000 (15:13 -0500)]
src.ctf.fs: little status code cleanup
Make ds_file_munmap return an enum ctf_msg_iter_medium_status, so it
integrates well with the rest. Adjust error handling around the call
sites to be more consistent.
Change-Id: Iea299c782dc215fc64cc3068e58e334f2acb85de
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 20:06:52 +0000 (15:06 -0500)]
src.ctf.fs: don't call ds_file_munmap on failure in ds_file_mmap_next
It seems useless to call ds_file_munmap here. We can reach the error
label either because:
- the previous call to ds_file_munmap has failed, in which case there's
no point in retrying
- the mmap call returned MAP_FAILED, in which case there's no point un
unmapping
Change-Id: Ia11716a967047d32773ab67f51bcf7516489f183
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 20:02:38 +0000 (15:02 -0500)]
src.ctf.fs: make ds_file_munmap assert that ds_file is not NULL
There is no reason for a NULL ds_file to ever be passed to this
function. Make it assert that the value is not NULL, to catch potential
mistakes.
Change-Id: I9261450f35b0a5c74ba182985ecabe2b31eee0a0
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 5 Nov 2019 19:59:11 +0000 (14:59 -0500)]
src.ctf.fs: rename some ctf_fs_ds_file fields
Rename these offset variables to make it a bit more obvious and explicit
what they are relative to. I find that it helps when reading to code, to
make sure that does the right thing.
Change-Id: Id676a482935f9b17553672160044456cc308883c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Mon, 4 Nov 2019 21:31:52 +0000 (16:31 -0500)]
src.ctf.fs: remove ctf_fs_ds_file_next
The function ctf_fs_ds_file_next is not really relevant, as it
doesn't deal with anything ds_file-specific anymore. It only calls the
ctf_msg_iter_get_next_message and translates the result to a
bt_component_class_message_iterator_next_method_status.
I think this job can (and should) be done by fs.c directly, as it's the
primary user/owner of the ctf_msg_iter.
This patch removes ctf_fs_ds_file_next and updates
ctf_fs_iterator_next_one to call ctf_msg_iter_get_next_message directly.
Change-Id: I96a9e1aa9d3c689bdf19f342464e1632c35058ca
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Mon, 4 Nov 2019 21:48:15 +0000 (16:48 -0500)]
ctf: const-ify a few bt_message parameters
I didn't understand at first why we needed a temporary local variable in
ctf_fs_iterator_next_one, why we couldn't just pass out_msg directly to
ctf_fs_ds_file_next. If we constify the parameter of
ctf_fs_ds_file_next, we can get rid of the variable. Doing so has a few
ramifications, it requires to constify the parameter in a few other
functions. But in the end I think it's all for the greater good.
Change-Id: Ie68249d38dae7a26ab8ce9341b436257644b3b10
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Mon, 4 Nov 2019 20:17:10 +0000 (15:17 -0500)]
ctf: remove ctf_fs_ds_file::msg_iter field
I find it strange that ctf_fs_ds_file objects knows about the
ctf_msg_iter that iterates on it. The ctf_fs_ds_file object just
represents some data that is accessible (a data stream file and the
portion currently mmap-ed), but I don't think it should know anything
about the iterating operation.
This patch removes the msg_iter field of ctf_fs_ds_file and adjusts the
code accordingly.
I think this change makes the code a bit clearer when we create
ctf_msg_iter objects. Currently, we create the msg_iter first with a
NULL medium ops data, then create the ctf_fs_ds_file. In
ctf_fs_ds_file_create, it sets the ctf_msg_iter's medium ops data to the
ctf_fs_ds_file.
With this patch, we create the ctf_fs_ds_file first. Then, when we
create the ctf_msg_iter, we can pass the ctf_fs_ds_file as the medium
ops data directly when we create the ctf_msg_iter.
Change-Id: I247f039d225888c059f08ccdccc86abf0816a6c4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 31 Oct 2019 22:28:54 +0000 (18:28 -0400)]
ctf: de-duplicate index entries
When trace snapshots were taken quickly enough, it's possible for them
to overlap. Some identical packets will be present in multiple
snapshots.
For example, the first snapshot could contain packets A, B and C while
the second snapshot could contain packets B, C, and D.
When reading those snapshots together with babeltrace, we will want to
present a coherent view of the logical trace that is spread across
multiple snapshots. That is, we will want to avoid reading the packet
twice.
Currently, we're not considering that case when building the building
the in-memory index. Processing the two streams above will lead to
those entries in the merged index:
- Packet A (snapshot 1)
- Packet B (snapshot 1)
- Packet B (snapshot 2)
- Packet C (snapshot 1)
- Packet C (snapshot 2)
- Packet D (snapshot 2)
This patch makes it so we only keep a single reference to each packet.
If a packet is duplicated, it doesn't matter to which snapshot the
reference points, since all copies of the packet are identical. So a
possible outcome of the situation above, with this patch applied, could
be:
- Packet A (snapshot 1)
- Packet B (snapshot 1)
- Packet C (snapshot 1)
- Packet D (snapshot 2)
So far the index is not used for much, so I don't think that this patch
will have any visible behavior change. However, an upcoming patch will
build on this to make it so we only read each packet once.
Change-Id: I00962d593b5078253043029902f853e5c3fa0dc5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Fri, 1 Nov 2019 19:17:46 +0000 (15:17 -0400)]
ctf: read packet sequence number from index
Starting with version 1.1, the CTF index format includes a packet
sequence number. Read it, if the index minor version is >=1. The index
major version is already checked to always be 1 above in the code.
If the version is lower than that, store UINT64_MAX in the
packet_seq_num field of the ctf_fs_ds_index_entry structure.
This information will be used in a subsequent patch.
Change-Id: I7b94a94344b26638ae4b7cfc4659067bebc7e195
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 7 Nov 2019 22:27:27 +0000 (17:27 -0500)]
Save and restore error in ctf_fs_iterator_next, muxer_msg_iter_do_next
ctf_fs_iterator_next and muxer_msg_iter_do_next are written in such a
way that if they successfully accumulate some messages, then hit an
error, they will return OK to make sure that those messages propagate
downstream in the graph, before the error stops the execution. This
assumes that the subsequent call to _next will fail again.
This poses a problem: when it returns OK in this case, it also leaves
the current thread error set. This is a postcondition breach.
One solution would be to simply clear the error in that case. This
would still rely on some error (perhaps the same, perhaps not) to be hit
again on the next _next call. What I don't like with that solution is
that the behaviour of the iterator, if we call _next again after a
failure, is hard to predict. We could hit the same error if we are
lucky, we could hit another error, we could hit an assertion because we
are in an unexpected state, etc.
Instead, this patch implements the following solution: return OK, but
take the error from the current thread and save it in the iterator. The
next time _next is called, that error is moved back to the current
thread and the error status is returned. This ensures that the error
the user will see is the one that originally caused the problem.
A test is added with a trace containing two valid events followed by an
invalid one. We expect to see the two events printed by the details
sink, as well as the error about the invalid event class id.
Change-Id: I725f1de0e6fa0b430aa34bfc524811c5dcd80fa3
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2353
Simon Marchi [Wed, 13 Nov 2019 19:13:06 +0000 (14:13 -0500)]
muxer: append causes on some _next iterator method code paths
The goal of this patch (on top of the fact that having more error causes
is nice) is to ensure that if an error status is returned to
muxer_msg_iter_do_next, an error is set on the current thread. This
will help for the next patch, which will save and restore the error in
this function.
Change-Id: I7221af107f330ab5ded10b69f24121be6ad1678c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2382
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Wed, 13 Nov 2019 20:36:42 +0000 (15:36 -0500)]
lib: save and restore current thread error when calling destruction listeners and finalize methods
Consider the following chain of events:
- User creates and runs a graph
- An error happens when running the graph, _ERROR is returned and the
current thread has an error
- The user does put_ref on the graph to clean up, deliberately leaving
the error on the current thread so it's processed above on the stack.
- When calling put_ref, a trace destruction listener is called.
- After calling the trace destruction listener, the lib asserts that no
error is set (BT_ASSERT_POST_NO_ERROR), which is not true, so the
assert fails.
In this case, the user of the graph would have to take the error, do the
put_ref and restore the error, if it wants to leave it for a function
higher in the stack. However, it is such a common scenario to hit an
error, do some put_ref to clean up and return the error, that it would
be very heavy (and error-prone) to have to do this all the time.
This patch makes it safe to call put_ref with an error set by wrapping
all the user code that can be called as a consequence of a put_ref
(destruction listeners and finalize methods) with an error take/move.
Before calling the user destruction listener or finalize method, the lib
saves the error on the stack. The user callback is therefore called
with no error set and the lib can still validate with
BT_ASSERT_POST_NO_ERROR that it leaves no error on the current thread
after returning. The error is then moved back.
We could say that put_ref now become "error-neutral", in that they can
be called with an error set on the current thread, and they won't modify
it.
Change-Id: I8c7a5429d53073483b9e03f0ec654c826466ee4e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2385
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Thu, 14 Nov 2019 02:13:07 +0000 (21:13 -0500)]
Cleanup: src.ctf.lttng-live: move function declarations around
* Remove declarations of `lttng_live_remove_stream_iterator()` and
`lttng_live_add_stream_iterator()` functions as they are not used.
* Move `lttng_live_need_new_streams()` function to viewer-connection.c
as it's only used in this file.
* Move declaration of `lttng_live_create_viewer_session()` to
viewer-connection.h
* Namespace `lttng_live_session` related functions with the
`lttng_live_session_` prefix.
* Rename `lttng_live_borrow_trace()` function to
`lttng_live_session_borrow_or_create_trace_by_id()`
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ie18423e9a39b4ac1e04642f381a9f59831c34abe
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2386
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Fri, 8 Nov 2019 21:01:03 +0000 (16:01 -0500)]
src.ctf.lttng-live: replace usage of `calloc()` by `g_new0()`
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I5c5ee34632488ff875b33b58fea67c16eb05f345
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2362
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Fri, 8 Nov 2019 20:32:05 +0000 (15:32 -0500)]
Fix: src.ctf.lttng-live: `fwrite()` does not set `errno`
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I212b6672c3793449aed800a518386ad10a499923
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2361
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Fri, 8 Nov 2019 18:34:01 +0000 (13:34 -0500)]
src.ctf.lttng-live: don't try to detach after socket error
Background
==========
The message iterator `_finalize()` method typically needs to detach from
the live session (LTTNG_VIEWER_DETACH_SESSION) so that the relay daemon
can free up the associated resources.
Issue
=====
In the case we encounter a socket error during the `_next()` method,
we don't want a component to try to send a detach command to the relay
during the `_iter_finalize()` method as this will surely lead to another
error. The annoying thing is that this other error would pollute the
error cause stack that lead to the first error.
Solution
========
Close the socket when we encounter an error and check in the
`lttng_live_detach_session` function if the socket it valid before
sending a _DETACH_SESSION command.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ic56e72013e78e4c5ef3343034b0e6f216599be6a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2357
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Thu, 7 Nov 2019 20:42:19 +0000 (15:42 -0500)]
Fix: src.ctf.lttng-live: decode metadata even on _STATUS_CLOSED
When receiving a _GET_ONE_METADATA_STATUS_CLOSED from the
`lttng_live_get_one_metadata_packet()` function it means that the
metadata stream was closed by the relay and we will no longer get any
new metadata. But, it also means that everything we received so far is
valid and can be decoded.
So rather than returning _LIVE_ITERATOR_STATUS_END the right thing to do
is to go on with the decoding of the metadata packets.
Also did the following cleanups:
* Merge the `lttng_live_metadata::trace` and
`lttng_live_trace::new_metadata_needed` into a new tri-state enum
`lttng_live_metadata_stream_state` in the `lttng_live_trace` struct.
Those two fields were tightly linked and it's simpler to have a single
field.
* Remove the "poking of the trace metadata" using the
`new_metadata_needed` as it's no longer necessary since all references
are now borrowed.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I3e18365d5cfeaa77935409bdfe8fdda52fa5b636
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2351
Francis Deslauriers [Thu, 7 Nov 2019 20:35:08 +0000 (15:35 -0500)]
Fix: src.ctf.lttng-live: removing trace when not all streams are done
The following commit wrongfully added the removal of a live trace
object:
commit
c28512ab93b16501a8b0da494f0a03e5f0f22662
Author: Francis Deslauriers <francis.deslauriers@efficios.com>
Date: Mon Oct 28 14:49:08 2019 -0400
src.ctf.lttng-live: make `lttng_live_get_one_metadata_packet()` return status
The live trace objects should only be removed once all its stream
iterator have ended. We do that in next_stream_iterator_for_session()
function.
So, roll back this change but keep the switch statement so it's clearer
what are the possible outcomes of the preceding function call.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I7ade43a256b731563eec2b1930724edbaeefd122
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2350
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Thu, 7 Nov 2019 17:36:20 +0000 (12:36 -0500)]
src.ctf.lttng-live: Add logging statements across the component class
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ib24204d48e43b91a5f0ad0111fe4e9d0abef5613
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2349
Francis Deslauriers [Wed, 6 Nov 2019 19:50:20 +0000 (14:50 -0500)]
Cleanup: src.ctf.lttng-live: rename live_iterator_status printing function
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I1512906e984e96893b737ed5388424e709223578
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2348
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Tue, 5 Nov 2019 22:01:14 +0000 (17:01 -0500)]
Cleanup: src.ctf.lttng-live: add `lttng_live_msg_iter_create()`
One small step to increase readability of this component class.
Change-Id: I4e690d96b85575847314e30ea9223806f4a049dc
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2343
Francis Deslauriers [Mon, 4 Nov 2019 17:07:22 +0000 (12:07 -0500)]
src.ctf.lttng-live: make component class handle interruptions
Currently, if a `src.ctf.lttng-live` component is interrupted by a
signal during a I/O syscall, it will return an _ERROR status downstream.
This is wrong for two reasons:
1. Some signals are not problematic (e.g. SIGUSR1) so we want to
continue as normal, and
2. we want to return an _AGAIN status when we receive a SIGINT
signal.
With this commit, when getting interrupted during a `recv()` or `send()`
call, we check if the graph is now in the interrupted state and return
the _AGAIN status if this case.
This commit changes the semantic of the lttng_live_{recv, send}
functions to make them return a status (_OK, _INTERRUPTED, or _ERROR).
The _OK status is only returned if the entire message was received or
sent. This allows us to remove many checks of the length of received or
sent data.
With this commit, once a live iterator is interrupted by SIGINT and
returns _AGAIN it's not in a state that can be recovered if the graph was
to be run again. Further work is needed to make this component class
restartable.
So to prevent user of the graph to call the _NEXT method after an
interruption, we mark the live iterator as interrupted (with the
`was_interrupted` boolean field) and return an error if it's the case.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I36cba1c3456250099ddfa9a2b15646c3e4f61e94
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2324
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Tue, 5 Nov 2019 19:25:15 +0000 (14:25 -0500)]
Fix: src.ctf.lttng-live: checking `errno` value on all errors
Issue
=====
We check the errno value even in cases where the errno is not set by the
function that witnessed the error.
For example, we have a `goto error;` after the
`lttng_live_get_one_metadata_packet() call.
Solution
========
Move the errno check right after the functions that set it on error.
Note
====
This erroneous change was introduced by this commit:
commit
c28512ab93b16501a8b0da494f0a03e5f0f22662
Author: Francis Deslauriers <francis.deslauriers@efficios.com>
Date: Mon Oct 28 14:49:08 2019 -0400
src.ctf.lttng-live: make `lttng_live_get_one_metadata_packet()` return status
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I7acb86984249658460888079fd7968d35f6d43fa
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2342
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Fri, 8 Nov 2019 16:08:10 +0000 (11:08 -0500)]
Cleanup: comp-logging.h: template `BT_COMP_OR_COMP_CLASS_LOG*` macros
This commit is motivated by the need to have the
`BT_COMP_OR_COMP_CLASS_LOGW_ERRNO()` logging macro in a future commit.
It adds the following template macros to simplify add logging macros for
other logging levels:
BT_COMP_OR_COMP_CLASS_LOG
BT_COMP_OR_COMP_CLASS_LOG_ERRNO
I didn't add the `BT_COMP_OR_COMP_CLASS_LOG_APPEND_CAUSE` template as
it's less likely that we will need it for logging levels other than
`BT_LOG_ERROR`.
Also, to be uniform across the file, I moved all the `_lvl` parameter to
the first position for all macros in this file.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ifbce021eecc08f8fc994a8ac0f4174ae3e1df853
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2354
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Mon, 11 Nov 2019 19:36:58 +0000 (14:36 -0500)]
lib: make bt_value_map_foreach_entry_{const_}func() return a status code
This patch makes the bt_value_map_foreach_entry_func() and
bt_value_map_foreach_entry_const_func() types return status codes
instead of `bt_bool`.
The available status codes are `OK` (continue the loop, like returning
`BT_TRUE` before this patch), `ERROR`, `MEMORY_ERROR`, and `INTERRUPT`
(break the loop, like returning `BT_FALSE` before this patch).
When the user function returns
`BT_VALUE_MAP_FOREACH_ENTRY_FUNC_STATUS_ERROR`,
bt_value_map_foreach_entry() returns
`BT_VALUE_MAP_FOREACH_ENTRY_STATUS_USER_ERROR` (set to the new global
status code `__BT_FUNC_STATUS_USER_ERROR`). This makes it possible to
distinguish between an internal library error and a user function error.
The purpose of this patch is to make it possible for a user function to
append an error cause to the current thread's error the same way other
user functions do: append the cause and return an error status.
For example, consider this scenario:
1. User calls bt_value_map_foreach_entry() with a user function and user
data which contains a status member.
2. User function calls a library function which fails. The library
function appends a cause to the current thread's error.
3. User function appends a cause to the current thread's error.
4. User function sets the user data's status member to the failing
library function's status and returns `BT_FALSE` to interrupt the
loop.
5. bt_value_map_foreach_entry() returns
`BT_VALUE_MAP_FOREACH_ENTRY_STATUS_INTERRUPTED` (not an error
status).
6. The caller of bt_value_map_foreach_entry() interprets
`BT_VALUE_MAP_FOREACH_ENTRY_STATUS_INTERRUPTED` as an error because
the user data's status member has an error value.
With this patch, it becomes:
1. User calls bt_value_map_foreach_entry() with a user function.
2. User function calls a library function which fails. The library
function appends a cause to the current thread's error.
3. User function appends a cause to the current thread's error.
4. User function returns `BT_VALUE_MAP_FOREACH_ENTRY_FUNC_STATUS_ERROR`
or `BT_VALUE_MAP_FOREACH_ENTRY_FUNC_STATUS_MEMORY_ERROR`, depending
on the failing library function's status, which breaks the loop.
5. bt_value_map_foreach_entry() appends a cause to the current thread's
error and returns `BT_VALUE_MAP_FOREACH_ENTRY_STATUS_USER_ERROR` or
`BT_VALUE_MAP_FOREACH_ENTRY_STATUS_MEMORY_ERROR`.
The latter seems more natural to me.
In Python, nothing wraps bt_value_map_foreach_entry() directly, so I
just converted bt_value_map_get_keys_cb() to return the appropriate
status instead of `BT_TRUE` or `BT_FALSE`. In other words,
bt2.utils._handle_func_status() does not need any change because it will
never receive `native_bt.__BT_FUNC_STATUS_USER_ERROR`.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I235d7957003b51630f4a2f72c1ccdef89d6173e8
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2365
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Mon, 4 Nov 2019 18:49:04 +0000 (13:49 -0500)]
Emit dedicated bright terminal color codes if supported
Some terminals support having a bold normal foreground color which is
_not_ bright. kitty is one of them, as well as GNOME Terminal with the
fairly recent "Show bold text in bright colors" option turned off (or
when calling the underlying vte_terminal_set_bold_is_bright() function
with the appropriate value).
An easy test is to execute:
$ echo -e "\033[31mTHIS\n\033[1mTHAT\033[0m"
and compare the colors of both lines: if they are the same, then the
terminal supports non-bright bold foreground colors.
For those terminals, the way to have a non-bold bright color is to emit
the dedicated SGR codes 90 to 97:
$ echo -e "\033[91mHELLO\033[0m"
Some terminals can print non-bold bright colors, but cannot print
non-bright bold colors.
This patch makes the Babeltrace project emit different color codes
depending on the connected terminal and the new
`BABELTRACE_TERM_COLOR_BRIGHT_MEANS_BOLD` environment variable's value:
kitty or `BABELTRACE_TERM_COLOR_BRIGHT_MEANS_BOLD` is `0`:
Output bright colors using dedicated SGR codes 90 to 97.
Otherwise:
Output bright colors with bold + SGR codes 30 to 37.
This patch effectively makes the Babeltrace modules emit correct bright
color codes for kitty.
To change as little as possible, I updated all the sites which emit a
bold code followed by a foreground color code to emit instead a bold
color code followed by a bright foreground color code. The only drawback
with the current approach is that, for non-kitty terminals, two bold
color codes are emitted for those cases (the real bold and the
brightening bold).
This means all bold colored text is also bright currently. Eventually we
can start decoupling the bold attribute from bright colors if need be,
although this means users must have a supporting terminal.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I3e0124942294fbe833d33aa59506c67e6ca85700
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2328
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Fri, 8 Nov 2019 22:19:13 +0000 (17:19 -0500)]
lib: add pre condition asserts to check current thread has no error
The user must not call an API function while the current thread has an
error set, especially a function that can itself fail and set an error.
Otherwise, causes from two unrelated errors will end up in the same
stack, which will produce some misleading information.
Add a precondition assertion to all API functions that are likely to
themselves set an error to the current thread, to verify that there is
not error on the current thread when they are called.
Change-Id: I9aadbc4e00d06f3e893970c7c8891dbe7c68606b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 7 Nov 2019 23:18:06 +0000 (18:18 -0500)]
lib: add post condition assertions for current thread error after user functions
It is a logic error and a post condition breach for a user function to
return a non-error status code (>= 0) but leave an error set on the
current thread. Add some assertions after each point where we call a
user function to catch this kind of mistake.
The macro BT_ASSERT_POST_DEV_NO_ERROR_IF_NO_ERROR_STATUS is meant to be
used in the very fast path (consume/next callbacks). The macro
BT_ASSERT_POST_NO_ERROR_IF_NO_ERROR_STATUS is used elsewhere.
The macros are written in such a way that if they cause an abort, the
error will still be present in thread_error, so accessible to a
debugger.
Change-Id: I4c6127c0b0258dac5be1e3bae63c2d9e6baa2d1f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Fri, 8 Nov 2019 20:04:01 +0000 (15:04 -0500)]
lib: clear error in clock_snapshots_are_monotonic_one
When bt_clock_snapshot_get_ns_from_origin is called in
clock_snapshots_are_monotonic_one, it can return OVERFLOW_ERROR, in
which case it also sets the current thread error.
clock_snapshots_are_monotonic_one doesn't report an error status to its
caller (it's not its goal), so it should not leave the error there.
This is exercised when running Python test
ClockSnapshotTestCase.test_clock_class.
Change-Id: I0f15c2607c299fabc3a89e6a292d97d8d5815fc4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2360
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 8 Nov 2019 19:05:37 +0000 (14:05 -0500)]
tests: clear error in test_simple_sink
When test_simple_expect_run_once_status is used to test an error case,
it leaves the current thread error set. The next test then starts with
an error already set, which is not right.
Clear the error at the end of test_simple_expect_run_once_status. And
while at it, validate that we have an error set exactly when an error
status is returned.
Change-Id: Iafb27908ed15b9e8a2a48bad9b58f3246a5ba3ca
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2359
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 8 Nov 2019 19:03:56 +0000 (14:03 -0500)]
lib: append error in simple_sink_consume only if error status
If the consume_func returns _AGAIN, we will append an error cause. That
is wrong because _AGAIN is not an error cause. Check for negative
status values instead of just != OK.
Change-Id: Ibc03a1e9eb25de5ec39af5148c8e235498c57b64
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2358
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Wed, 6 Nov 2019 21:02:35 +0000 (16:02 -0500)]
src.ctf.fs: rename pc_msg_iter parameter to self_msg_iter
This is a leftover of:
f30762e5afa0 ("Rename pc_msg_iter fields to self_msg_iter")
Change-Id: I770e3d9a5d903e49a03051ee7c0bef0cdad38cd5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2347
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Mon, 4 Nov 2019 19:55:11 +0000 (14:55 -0500)]
Cleanup: cli: move LOGE statements closer to the source
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I752ff78e043e4948489360c5b4e4206a5350c9fd
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2329
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Tue, 29 Oct 2019 21:45:09 +0000 (17:45 -0400)]
cli: exit with status 2 when interrupted by SIGINT
With this commit, users of the CLI issuing a ctrl+c to interrupt a
running graph will not get an error cause stack printed to stderr.
Instead, they will now simply get a non-zero exit status to signify that
the execution of the command did not complete as expected.
We preferred this approach, because we consider it unexpected that a
user who willingly pressed ctrl+c to stop the command ends up getting an
error cause stack printed to the CLI.
As the execution did not complete normally, we also did not want the
command to exit with status 0 in such cases. Exiting with status code 1
was also not appropriate as it is typically used to signify an error.
In sum, the middle ground we found, is to exit with status code 2 and
not print an error message.
This commit adds tests to confirm that the right exit status is produced
by the CLI when a graph is interrupted, is erroring, or is returning
successfully. To do this, this commit adds a custom Python source
component class that takes as parameter the name of the scenario to
produce during its iterator's first `_next()` call. The iterator then
does the needful to put the graph in the right condition. We then test
if the CLI exits with the expected status.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I82a451b24240be6fb2256ce681685ba02b73600f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2308
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Tue, 5 Nov 2019 02:47:20 +0000 (21:47 -0500)]
Update version to v2.0.0-rc2
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ifd82afac0bb19c9776d955e52b197ad3b7375bab
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2334
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Wed, 30 Oct 2019 19:20:20 +0000 (15:20 -0400)]
Ignore -Wcast-function-type warning
We get this when building on CentOS 8:
bt2/native_bt.c:1819:23: error: cast between incompatible function types from ‘PyObject * (*)(PyObject *)’ {aka ‘struct _object * (*)(struct _object *)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} [-Werror=cast-function-type]
{(char *)"disown", (PyCFunction)SwigPyObject_disown, METH_NOARGS, (char *)"releases ownership of the pointer"},
^
bt2/native_bt.c:1820:23: error: cast between incompatible function types from ‘PyObject * (*)(PyObject *)’ {aka ‘struct _object * (*)(struct _object *)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} [-Werror=cast-function-type]
{(char *)"acquire", (PyCFunction)SwigPyObject_acquire, METH_NOARGS, (char *)"acquires ownership of the pointer"},
^
bt2/native_bt.c:1823:23: error: cast between incompatible function types from ‘PyObject * (*)(PyObject *)’ {aka ‘struct _object * (*)(struct _object *)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} [-Werror=cast-function-type]
{(char *)"next", (PyCFunction)SwigPyObject_next, METH_NOARGS, (char *)"returns the next 'this' object"},
^
bt2/native_bt.c:1824:23: error: cast between incompatible function types from ‘PyObject * (*)(SwigPyObject *)’ {aka ‘struct _object * (*)(struct <anonymous> *)’} to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’} [-Werror=cast-function-type]
{(char *)"__repr__",(PyCFunction)SwigPyObject_repr, METH_NOARGS, (char *)"returns object representation"},
^
See comment in configure.ac for detailed explanation. It would have
been nice to just disable it when building native_bt.c, but I am not
sure how to do that in a way that's compatible with all compilers and
that is not overly complicated. So let's just disable it globally for
now.
Change-Id: Iae5c5b6d96978f00e8b19098a438c60817226393
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2309
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Fri, 1 Nov 2019 15:29:36 +0000 (11:29 -0400)]
Cleanup: src.ctf.lttng-live: remove redundant _APPEND_CAUSE()
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I7336fd9e9fe81ddc6194b00c84a4875e0b5609a8
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2319
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Mon, 4 Nov 2019 20:28:38 +0000 (15:28 -0500)]
cli: set `bt_config::command_name` field for all commands
This field is used in babeltrace2.c to print the pretty print the
command name in different logging messages.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I953ea162a33212157236be5295183e39fb866ff4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2331
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Fri, 1 Nov 2019 19:31:02 +0000 (15:31 -0400)]
src.ctf.fs: make log macros of data-stream-file.c more generic
The logging macros in data-stream-file.c currently assume that all the
contexts where a logging statement is used will have a self component at
ds_file->self_comp and a logging level at ds_file->log_level. In a
future patch, I'd like to use a logging statement where there is no
reason to pass a ds_file variable.
Make the macros more generic by having them refer to just self_comp and
logging_level.
Change-Id: I0057dd27310e6ca6bf18441e214eb2fe8a25b19e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2326
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Mon, 4 Nov 2019 17:08:53 +0000 (12:08 -0500)]
ctf: check version of LTTng trace index
If LTTng was to start producing trace index files with major version 2,
it would presumably be because the format has become
backwards-incompatible. Babeltrace would currently try to parse it like
it parses version 1.x index files, and that would likely not give good
results.
This patch makes Babeltrace check the major version of LTTng trace index
files before parsing them, and ignore them if the major version is not 1.
Change-Id: Ieb4a795a3fce1f5196a2b4ab44575da1b4fc1364
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2325
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Sun, 3 Nov 2019 02:09:50 +0000 (22:09 -0400)]
ctf: save self_msg_iter in ctf_msg_iter when creating it
I find it strange that we assign ctf_msg_iter::self_msg_iter in
ctf_msg_iter_get_next_message. The self_msg_iter associated to the
ctf_msg_iter is the same throughout its lifetime, and known at creation
time, so we can assign it once at creation time.
This patch adds a self_msg_iter to ctf_msg_iter_create to do that. It
also removes the self_msg_iter parameter from
ctf_msg_iter_get_next_message, since it is not needed anymore.
Some ctf_msg_iter instances are created not in the context of a
bt_self_message_iterator (e.g. when we create a src.ctf.fs component
and we need to build an index). For those cases, we pass NULL.
Change-Id: I0890dd2504097cf038fd40ec6a1ce1dc099008b2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2323
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Mon, 4 Nov 2019 16:33:33 +0000 (11:33 -0500)]
ctf: rename bt_msg_iter to ctf_msg_iter
The bt_msg_iter structure is specific to iterating on CTF messages, so
it would be more appropriate for it to be called ctf_msg_iter. Rename
it, as well as related types and functions.
Change-Id: I0ce498e492295a3f7390d73d921ef2eca1cc6d00
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2322
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Sat, 2 Nov 2019 13:09:29 +0000 (09:09 -0400)]
ctf: rename bt_msg_iter::msg_iter to self_msg_iter
This follows the naming convention that I have used so far. It helps
knowing which kind of msg iter we are talking about, given that there
are multiple kinds.
Change-Id: Ifece52b06312b0c5f878313171ca4973643e305d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2320
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Sun, 3 Nov 2019 03:23:03 +0000 (23:23 -0400)]
Rename pc_msg_iter fields to self_msg_iter
The pc prefix means "private connection", which is not a concept
present in the API anymore. Rename to "self_msg_iter", which is a more
contemporary term.
Change-Id: I76ab362cab05d1dd480549fc285060854375e1e7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2321
CI-Build: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Sat, 2 Nov 2019 02:49:59 +0000 (22:49 -0400)]
bt_common_abort(): optionally execute a custom command before aborting
This patch makes bt_common_abort() execute the value of the
`BABELTRACE_EXEC_ON_ABORT` environment variable, if it's set, as a shell
command line if the setuid/setgid flags are NOT set (for security).
The function uses g_spawn_command_line_sync() which claims to parse the
command line string like a UNIX 98 shell would, so that's what I wrote
in the environment variable's description in the manual page.
You can use this to execute any command when any part of the Babeltrace
project would abort, for example report it to some system.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I78801460b316f04d805162af320ee30028dc90de
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2318
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sat, 2 Nov 2019 02:20:33 +0000 (22:20 -0400)]
Add bt_common_abort() and use it instead of abort() directly
This patch adds bt_common_abort() which, for the moment, only calls
abort().
This patch also replaces all the calls to abort() with calls to
bt_common_abort().
The purpose is to control how all the parts of Babeltrace abort,
eventually adding other actions before calling abort() for example.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2c8cd7ad760758041ef2dcaaa6b3ef84f89d80e6
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2317
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Sat, 2 Nov 2019 02:22:20 +0000 (22:22 -0400)]
.gitignore: add missing `/tests/param-validation/test_param_validation`
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Iba60cf173cdbcbf9986758a548ed732cc3008454
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2316
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Sun, 3 Nov 2019 03:11:51 +0000 (23:11 -0400)]
ctf: fix typo
Change-Id: I225bd8b32ee2491c157c85d20cf7ed508e8851c1
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Thu, 31 Oct 2019 16:32:33 +0000 (12:32 -0400)]
Cleanup: src.ctf.lttng-live: add missing `#include <stdint.h>`
Use stdint.h whenever only uint*_t are need and inttypes.h when
printf-like identifier are need (e.g. %PRIu64).
And reorder some #include statements.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ic69636e4ac316a86f88ba0bdd8ad435b38db0e6a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2313
Francis Deslauriers [Thu, 31 Oct 2019 15:40:27 +0000 (11:40 -0400)]
Cleanup: src.ctf.lttng-live: remove usage of `bt_object`
The live_viewer_connection objects are never shared and we can know that
by seeing that there is no to _get_ref() in this entire component class.
This commit also removes the need for the BT_OBJECT_DONT_LOG macro added
by:
commit
9358ceb38baa2d50a69d7ee580463a2ddba25465
Author: Philippe Proulx <eeppeliteloop@gmail.com>
lib/object.h: log conditionally to `BT_OBJECT_DONT_LOG` undefined
so remove that to.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I2b4ba20613e77048044507a93241bf7db3f58fa2
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2312
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Thu, 31 Oct 2019 17:40:07 +0000 (13:40 -0400)]
lib: lib-logging.c: `Babeltrace library` -> `libbabeltrace2`
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ibb0de3faa3bdc30fcead46467a69d8ece5d5792f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2314
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Tue, 22 Oct 2019 19:39:44 +0000 (15:39 -0400)]
ctf: msg-iter.c: rename `notit` to `msg_it`
Messages used to be called notifications. The CTF message iterator used
to be called notification iterator. This explains why the msg-iter.c
file has tons of variables and parameters named `notit`.
I believe it's time to rename them to a proper name: `msg_it`.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: If546b53a9bca2495fb1cfaf0232d528478e659cf
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2244
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Tue, 22 Oct 2019 19:23:06 +0000 (15:23 -0400)]
ctf: msg-iter.c: use `_APPEND_CAUSE` variants of logging macros
This commit also changes usage of logging level macros `LOGW` in this
file to use `LOGE` which is more appropriate when returning
_STATUS_ERROR. All callers of this API consider _STATUS_ERROR as
un-recoverable.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ie44d98e0285bdcf2c3ed7f2aeeb1af0cfadef5d4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2243
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Tue, 22 Oct 2019 16:28:23 +0000 (12:28 -0400)]
src.ctf.lttng-live: use `_APPEND_CAUSE` variants of logging macros
This commit adds `BT_COMP_CLASS_LOGE()` and
`BT_COMP_OR_COMP_CLASS_LOGE()` macros for convenience.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I86b9bbe89574d40fa5e65297a166ca0e7cff54a2
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2242
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Tue, 29 Oct 2019 19:55:29 +0000 (15:55 -0400)]
src.ctf.lttng-live: make `lttng_live_attach_session()` return status
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Id7a2924ea9f5ac91bf9848995029e3c6edb9a4d3
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2306
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Mon, 28 Oct 2019 18:49:08 +0000 (14:49 -0400)]
src.ctf.lttng-live: make `lttng_live_get_one_metadata_packet()` return status
This is needed to differentiate real critical errors from relay daemon
from errors which are handled.
The relay daemon can return the LTTNG_VIEWER_METADATA_ERR status to
convey that the requested metadata stream is not found of the relay.
This can happen during normal operations if the associated trace is no
longer active. Short lived UST apps in per-pid session may produce such
scenario. In these cases, simply remove the live trace from the session
and go on with the iteration.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I452e63bd12a3c58d518726e3d178be241464bc2a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2277
Simon Marchi [Mon, 28 Oct 2019 18:40:16 +0000 (14:40 -0400)]
logging: ignore -Wundef in log.c
When building with -Wundef enabled, I get this warning:
/home/smarchi/src/babeltrace/src/logging/log.c: In function ‘put_tag’:
/home/smarchi/src/babeltrace/src/logging/log.c:455:15: error: "_BT_LOG_MESSAGE_FORMAT_MASK__TAG" is not defined, evaluates to 0 [-Werror=undef]
_PP_CONCAT_3(_BT_LOG_MESSAGE_FORMAT_MASK_, _, field)
^
/home/smarchi/src/babeltrace/src/logging/log.c:350:30: note: in definition of macro ‘_PP_PASTE_3’
#define _PP_PASTE_3(a, b, c) a ## b ## c
^
/home/smarchi/src/babeltrace/src/logging/log.c:455:2: note: in expansion of macro ‘_PP_CONCAT_3’
_PP_CONCAT_3(_BT_LOG_MESSAGE_FORMAT_MASK_, _, field)
^~~~~~~~~~~~
/home/smarchi/src/babeltrace/src/logging/log.c:470:3: note: in expansion of macro ‘_BT_LOG_MESSAGE_FORMAT_MASK’
(_BT_LOG_MESSAGE_FORMAT_MASK(field) & _BT_LOG_MESSAGE_FORMAT_FIELDS(format))
^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/smarchi/src/babeltrace/src/logging/log.c:1151:6: note: in expansion of macro ‘_BT_LOG_MESSAGE_FORMAT_CONTAINS’
#if !_BT_LOG_MESSAGE_FORMAT_CONTAINS(TAG, BT_LOG_MESSAGE_TAG_FORMAT)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That code comes from zf_log and is a big mess of macros, I don't know
how to fix that. However, I'd like to enable -Wundef, given that it has
found a relatively important bug (see commit
9103e903a8 "Fix: define
macros for logging levels"). So, silence -Wundef just for that
particular spot.
Change-Id: I42fece6a04c3715daea873683c350b2987c500e5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2278
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Wed, 30 Oct 2019 21:50:40 +0000 (17:50 -0400)]
lib: Make `bt_version_get_*() return unsigned int
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I153fb51c5065e672f4ffe05513151238944fb565
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2311
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Wed, 30 Oct 2019 21:47:25 +0000 (17:47 -0400)]
Rename `BT_RANGE_SET_` to `BT_INTEGER_RANGE_SET_`
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ibf20111c88f4a980d858cecd297bf6285cbbb4ee
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2310
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Mon, 28 Oct 2019 21:00:11 +0000 (17:00 -0400)]
bt2: validate parameters to _TraceClass.create_stream_class before creating the native object
When creating a stream class (in _TraceClass.create_stream_class), we
start by creating the native object, then assign each property passed
as arguments to create_stream_class.
If the value of a parameter is invalid (e.g. wrong type), we will raise
an exception. The problem is that at this point, the stream class
object has already been created and added to its parent, the trace
class. This leaves the user in an uncomfortable position, where a
stream class has been created, with the parameters only partially
applied, while an exception was raised.
Instead, the stream class native object should be created only once we
know that all the parameters are valid. This patch makes it so we
validate all parameters before calling the native creation function.
Given that the setters in _StreamClass are internal and only used in
_TraceClass.create_stream_class, we don't need to validate the values of
the parameters again in them.
I have added tests for two conditions that weren't tested, when passing
a wrong parameter type to assigns_automatic_event_class_id and
assigns_automatic_stream_id.
Otherwise, I added assertions to the test to make sure that when the
stream class Python object couldn't be created, no stream class object
was added as a child of the trace class.
Change-Id: I18cbb2e8128cf49e6a6411a225352f279aec5d02
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2279
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Tue, 29 Oct 2019 19:27:26 +0000 (15:27 -0400)]
tests: use assertRaisesRegex instead of assertRaises in test_stream_class.py
Using assertRaises is not very robust. We can expect a ValueError to be
raised, but in reality the test can pass because a ValueError different
than the one we are expecting is raised, and we don't actually test what
we mean to.
Use assertRaisesRegex throughout test_stream_class.py, which validates
the exception message in addition to the type.
I have also updated a few exception messages in the process, where I
thought they could be made clearer.
Change-Id: I1419950521210e778fb49f7b92f6563c546f0150
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2304
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Tue, 29 Oct 2019 16:59:36 +0000 (12:59 -0400)]
Cleanup: add `#include <stdbool.h>` whenever `bool` type is used
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I1984ff361c8197efd44928a6fc6889fa60cfdc33
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2303
Philippe Proulx [Tue, 29 Oct 2019 15:29:12 +0000 (11:29 -0400)]
lib: remove `BT_GRAPH_RUN_STATUS_END`
This patch makes bt_graph_run() return `BT_GRAPH_RUN_STATUS_OK` when the
graph is done running instead of `BT_GRAPH_RUN_STATUS_END`, as one of
them is redundant here and keeping an OK status looks like the right
decision.
bt_graph_run_once() is different: it returns
`BT_GRAPH_RUN_ONCE_STATUS_OK` once it's done running a single time, and
eventually `BT_GRAPH_RUN_ONCE_STATUS_END` when all the sink components
are ended.
In bt2.Graph.run(), the special case for `bt2.Stop` is removed as
`status` is never `BT_GRAPH_RUN_STATUS_END`.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I9d642292083c3bce0b7be263242f5b23d3713735
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2281
CI-Build: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Francis Deslauriers [Wed, 23 Oct 2019 00:52:02 +0000 (20:52 -0400)]
Cleanup: ctf: msg-iter.c: rename `ret` to `status`
This is to follow the coding style of the rest of the file and most of
the project.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ibdc1adcc8eef7d95df2c69113bc20228c4d00b9b
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2247
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Wed, 23 Oct 2019 00:47:37 +0000 (20:47 -0400)]
Cleanup: ctf: remove duplicated logging statement
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ica4fa11646a59ddbfb6cd4c2a9cd108846ffd6dc
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2246
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Wed, 30 Oct 2019 14:01:12 +0000 (10:01 -0400)]
Cleanup: msg-iter.c: make `create_msg_*()` return msg
Those functions have a void return type but are returning the created
message using an output parameter.
Make them return the message instead.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Iff60a9436818f38d5b5046b921c0d53cdc1f2c66
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2307
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Tue, 29 Oct 2019 19:45:09 +0000 (15:45 -0400)]
Cleanup: src.ctf.lttng-live: NULL check already done in `_is_canceled()` func
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I85e4638a326a04889bc6cf5f491fdab8884047ef
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2305
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Fri, 25 Oct 2019 21:56:36 +0000 (17:56 -0400)]
cli: Remove unnecessary NULL check in print_value_rec
There's no reason for `value` to legitimately be NULL here. Replace
that with an assert so we can catch eventual mistakes.
Change-Id: I9272c4c5e862601d7c9c7b9c67a1cf332ee1770b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2265
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Jérémie Galarneau [Fri, 25 Oct 2019 21:43:47 +0000 (17:43 -0400)]
source.ctf.lttng-live: clean-up: don't restart session iteration
Don't restart the iteration on a session array when a session has to
be removed. The contents of the array's current position are replaced
by the contents of the last position in the array. Thus, we can
continue the iteration from the current index.
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: If058fe4b10c9c422b9f54edd63900b6804bbe8e2
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2264
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Jérémie Galarneau [Fri, 25 Oct 2019 21:41:50 +0000 (17:41 -0400)]
source.ctf.lttng-live: clean-up: don't restart stream iteration
Don't restart the iteration on a stream array when a stream has
to be removed. The contents of the array's current position are
replaced by the contents of the last position in the array. Thus,
we can continue the iteration from the current index.
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ia465f2995d6ee0ad1241063bc62e92cbf40745eb
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2263
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Jérémie Galarneau [Fri, 25 Oct 2019 21:32:42 +0000 (17:32 -0400)]
Fix: source.ctf.lttng-live: assertion on equal messages
The following assertion fails when consuming a per-pid trace
of short-lived applications.
(╯°□°)╯︵ ┻━┻ muxing.c:849: common_muxing_compare_messages(): Assertion `left_msg != right_msg` failed.
The live source performs a muxing step during which it can see that a
trace has ended. When that happens, the trace is removed from the
array of traces and the iteration on that array resumes from the
beginning. This causes the message comparator to assert as two
identical messages can be compared.
Not reseting the trace index to 0 causes the iteration to continue
from the same position in the array. This is fine since the "fast"
variant of the glib pointer array removal function replaces the
removed pointer by the last one. This is both more efficient and
solved the problem of comparing a message to itself (the oldest
message) during a second pass on the traces array.
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I5045a0483b17f0bcb48ff7eb0d88f82bf19f68d4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2262
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Jérémie Galarneau [Tue, 29 Oct 2019 16:08:09 +0000 (12:08 -0400)]
Add compile_commands.json to .gitignore
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I720985a14e3419ff7c3f5b8dba79b2b8894eb28e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2302
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Francis Deslauriers [Fri, 25 Oct 2019 15:17:45 +0000 (11:17 -0400)]
Cleanup: src.ctf.lttng-live: coding style
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I31d1f0c9503de42be969fb67a294c9cf7548d441
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2266
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 29 Oct 2019 15:47:56 +0000 (11:47 -0400)]
Fix: add missing decoder-packetized-file-stream-to-buf.h
The previous commit (
b8433fc, "Fix: add missing
decoder-packetized-file-stream-to-buf.h") was missing this file.
Change-Id: Ib7f1782b4ca0e12abb59b69e4213b899003128a7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2301
Simon Marchi [Mon, 28 Oct 2019 15:06:04 +0000 (11:06 -0400)]
Fix -Wmissing-prototypes/-Wmissing-declarations warnings
I think this warning is useful because it catches a lot of instances
where we missed including "foo.h" in "foo.c" or where we should make a
function static.
There are changes in this patch I am not sure about:
bt_ctf_event_borrow_stream: there doesn't seem to be any "borrow"
functions in the CTF writer API, only get (which return new references),
so I presume this is one is not meant to be exposed. I made it static.
_bt_ctf_event_freeze: is not used anywhere, starts with an underscore,
so I presume it was meant to be internal, so I removed it.
bt_ctf_event_common_set_payload: it sounds like something that was meant
to be exposed internally, so I added a declaration to the internal
event.h.
bt_ctf_event_class_get_payload_type_*: they seem like functions that are
meant to be exposed in the external API, so I added declarations in the
external event.h.
bt_ctf_field_type_enumeration_mapping_iterator_next: it probably needs
to be exposed to make the functions which return a
bt_ctf_field_type_enumeration_mapping_iterator useful.
bt_ctf_field_type_enumeration_mapping_iterator_signed_get and
bt_ctf_field_type_enumeration_mapping_iterator_unsigned_get: same as
above.
bt_ctf_trace_visit: I guess it's meant to be exposed, so I added a
declaration in the internal trace.h.
bt_self_component_port_input_message_iterator_borrow_component_const: I
guess this should not exist, because hand out const versions of
bt_self_component_port_input_message_iterator? I removed it.
bt_plugin_python_create_all_from_file: adding an include of
python-plugin-provider.h in python-plugin-provider.c revealed that the
declaration was way out of sync with the definition, I've tried to fix
that (and succeeded!).
Change-Id: I423d70645dbb1305f8993ec837131883bce47031
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2275
Simon Marchi [Mon, 28 Oct 2019 02:12:41 +0000 (22:12 -0400)]
ctf: Remove redundant declarations of lexer/parser functions
I get these warnings:
CC libctf_parser_la-lexer.lo
lexer.c:857:17: error: redundant redeclaration of ‘yyunput’ [-Werror=redundant-decls]
857 |
| ^
/home/simark/src/babeltrace/src/plugins/ctf/common/metadata/lexer.l:55:13: note: previous declaration of ‘yyunput’ was here
55 | static void yyunput (int c, register char * yy_bp , yyscan_t yyscanner)
| ^~~~~~~
CC libctf_parser_la-lexer.lo
lexer.c:871:12: error: redundant redeclaration of ‘input’ [-Werror=redundant-decls]
871 | #else
| ^
/home/simark/src/babeltrace/src/plugins/ctf/common/metadata/lexer.l:55:12: note: previous declaration of ‘input’ was here
55 | static int input (yyscan_t yyscanner) __attribute__((unused));
| ^~~~~
CC libctf_parser_la-parser.lo
/home/simark/src/babeltrace/src/plugins/ctf/common/metadata/parser.y:63:5: error: redundant redeclaration of ‘yyparse’ [-Werror=redundant-decls]
63 | int yyparse(struct ctf_scanner *scanner, yyscan_t yyscanner);
| ^~~~~~~
In file included from /home/simark/src/babeltrace/src/plugins/ctf/common/metadata/parser-wrap.h:41,
from /home/simark/src/babeltrace/src/plugins/ctf/common/metadata/parser.y:47:
parser.h:192:5: note: previous declaration of ‘yyparse’ was here
192 | int yyparse (struct ctf_scanner *scanner, yyscan_t yyscanner);
| ^~~~~~~
Because of the __attribute__((unused)), when removing the declarations
of yyunput and input from lexer.l, I expected to get a
"-Wunused-function" warning. But that doesn't seem to be the case (even
when manually enabling -Wunused-function), so I'm giving a shot at
removing those declarations, since they may not be essential.
The yyparse declaration is not essential, since there's one already in
the generated parser.h.
There is a slight possibility that older bison versions (I'm using
3.4.2) produce different results, but I can't easily test right now.
Change-Id: I73ff02896db1f40d476757b3207629a3ff20ac39
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/2274
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
This page took 0.051415 seconds and 4 git commands to generate.