Francis Deslauriers [Fri, 5 Jul 2019 05:11:10 +0000 (01:11 -0400)]
bt2: namespace private attributes of inheritable classes
Add `_bt` prefix to all private attributes and methods of classes of
which the user can inherit. This is done to prevent attribute name
clashes between the base class and the user class. We will document that
the user must not have any attribute with the `_bt_` prefix.
Here are the attribute and method names of inheritable classes with this
commit:
_UserSinkComponent:
self._add_input_port
self._bt_as_component_class_ptr
self._bt_as_component_ptr
self._bt_as_not_self_specific_component_ptr
self._bt_as_self_component_ptr
self._bt_borrow_component_class_ptr
self._bt_cc_ptr
self._bt_comp_cls_type
self._bt_graph_is_configured_from_native
self._bt_port_connected_from_native
self._bt_ptr
self._consume
self._create_clock_class
self._create_trace_class
self._finalize
self._input_ports
self._port_connected
self.addr
self.cls
self.logging_level
self.name
_UserMessageIterator:
self._bt_can_seek_beginning_from_native
self._bt_init_from_native
self._bt_next_from_native
self._bt_ptr
self._bt_seek_beginning_from_native
self._bt_validate_stream_activity_message_default_clock_snapshot
self._can_seek_beginning
self._component
self._create_discarded_events_message
self._create_discarded_packets_message
self._create_event_message
self._create_message_iterator_inactivity_message
self._create_packet_beginning_message
self._create_packet_end_message
self._create_stream_activity_beginning_message
self._create_stream_activity_end_message
self._create_stream_beginning_message
self._create_stream_end_message
self._finalize
self._infinite_clock_snapshot
self._seek_beginning
self._unknown_clock_snapshot
self.addr
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ia42f247038cc3d054199a8c94becddcb088b646a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1626
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Thu, 4 Jul 2019 01:43:40 +0000 (21:43 -0400)]
tests: bt2: use `addr` attribute instead of private `_ptr`
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I5e8ae217d0d3869207af3fa0c92e05a6fabc1a16
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1624
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 5 Jul 2019 17:31:44 +0000 (13:31 -0400)]
cli: fix typo in error message
The lttng-live component can be used with the --input-format switch, not
--output-format.
Change-Id: I6217d52756373f5db3a123bb2aeb209a8c6789c8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1639
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Tue, 25 Jun 2019 15:01:30 +0000 (11:01 -0400)]
Fix: src.ctf.fs: segfault following `bt_msg_iter_seek()`
Issue
=====
Seeking a `bt_msg_iter` right after its creation leaves its `mmap_addr`
field uninitialized which may lead to a segmentation fault when
`medop_request_byte()` is called.
It triggers a segfault in `medop_request_byte()` because
`ds_file->mmap_len` field is 0 and `ds_file->request_offset` field is
larger than 0. This makes the call to `remaining_mmap_bytes()` return
non-zero.
It makes it so that the call to `ds_file_mmap_next()` is skipped and
`ds_file->mmap_addr` is dereferenced without being initialized.
The real underlying issue is that `medop_seek()` returns success even
when no file is mapped.
Solution
========
When seeking, map the right file if `mmap_addr` is still uninitialized.
Drawback
========
None.
Notes
=====
I also added comments and `BT_ASSERT()` that helped me track down this
issue and that I believe could be useful for other developers.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I041dc89159953a6ffce016b8c094969fb9c3f862
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1532
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Wed, 12 Jun 2019 20:32:46 +0000 (16:32 -0400)]
Fix: src.ctf.fs: trace-info: port_name memory leak
Valgrind report:
==21704== 256 bytes in 4 blocks are definitely lost in loss record 29 of 38
==21704== at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21704== by 0x555EA1F: g_realloc (gmem.c:164)
==21704== by 0x557AF56: g_string_maybe_expand (gstring.c:102)
==21704== by 0x557B2E4: g_string_insert_len (gstring.c:476)
==21704== by 0x557B44C: g_string_assign (gstring.c:349)
==21704== by 0x6B2D8C5: ctf_fs_make_port_name (fs.c:427)
==21704== by 0x6B31FCD: populate_stream_info (query.c:342)
==21704== by 0x6B321E9: populate_trace_info (query.c:417)
==21704== by 0x6B32592: trace_info_query (query.c:525)
==21704== by 0x6B3104C: ctf_fs_query (fs.c:2326)
==21704== by 0x4E7ED6A: bt_query_executor_query (query-executor.c:128)
==21704== by 0x10DCDA: query (babeltrace2.c:201)
Reported-by: Valgrind Memcheck
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I4e8ac593327d170005fd984ef7744656e7feb47d
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1419
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 5 Jul 2019 14:58:45 +0000 (10:58 -0400)]
bt2: remove probing of BABELTRACE_PYTHON_BT2_NO_TRACEBACK env var
This was used previously when handling exceptions thrown by user code,
to decide whether we printed exceptions or not. Nowadays, we let
exceptions propagate to the native code, which logs it. I believe we
can remove this.
Change-Id: I14adae265c83a169d176dda9d83d4d05fcd26edc
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1636
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Thu, 4 Jul 2019 20:31:00 +0000 (16:31 -0400)]
trimmer: use g_match_info_free instead of g_match_info_unref
The build fails with glib 2.22:
trimmer.c: In function ‘compile_and_match’:
trimmer.c:201:3: error: implicit declaration of function ‘g_match_info_unref’; did you mean ‘g_match_info_free’? [-Werror=implicit-function-declaration]
g_match_info_unref(*match_info);
^~~~~~~~~~~~~~~~~~
g_match_info_free
The g_match_info_unref function is only available from glib 2.30. Use
g_match_info_free instead, which does the same for our use case.
Change-Id: I9357b9dd18501749e19481e9ef08ec9b01379ee6
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1633
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Wed, 3 Jul 2019 19:21:09 +0000 (15:21 -0400)]
tests: bt2: Fix `run_python_bt2` usage example
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I873b18a351b66f0559987ed0e32aa455b7b4e7d6
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1607
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Wed, 3 Jul 2019 15:34:02 +0000 (11:34 -0400)]
CONTRIBUTING.adoc: add how to run `bt2` tests
This commit adds a tiny testing section containing an introduction and a
few useful commands to run the `bt2` tests.
Philippe will without a doubt rework this section upon the release of
Babeltrace 2.0. So this commit simply adds commands useful to developers
in the meantime.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: If4be315ddcc09efe9224e42de62c5b01c73ead8f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1602
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Wed, 3 Jul 2019 21:40:52 +0000 (17:40 -0400)]
tests: bt2: add `--test-case` argument to testrunner.py
The `-t/--test-case` argument allows to specify the exact test case to
run.
Make the `--test-case` and the existing `--pattern` options mutually
exclusive and require that one of the two is provided.
It can be used like this:
./tests/utils/run_python_bt2 python3 ./tests/utils/python/testrunner.py \
-t test_event.EventTestCase.test_clock_value \
./tests/bindings/python/bt2
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Icc9204d05bac4cef9cc509f2b19a9e515b0a40e7
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1612
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Francis Deslauriers [Fri, 5 Jul 2019 15:19:32 +0000 (11:19 -0400)]
Fix: src.ctf.fs: pointer arithmetics on non-adjacent memory
Issue
=====
When indexing a trace using `*.idx` files, if streams span more than one
packet the user may witness the following warning message:
W PLUGIN/SRC.CTF.FS/DS build_index_from_idx_file@data-stream-file.c:400
[source-ctf-fs] Invalid, non-monotonic, packet offset encountered in
LTTng trace index file: previous offset=
14757395258967641292, current offset=4096
This is caused by the fact the we're using pointer arithmetics to get
the pointer to the previous entry of an array. This ends returning
garbage because it's a pointer array and not a regular array storing the
objects as the code expects to.
This regression was most probably introduced by the following commit:
commit
7ed5243afe12c7c12fa5305fff99b93ad23bbdff
Author: Francis Deslauriers <francis.deslauriers@efficios.com>
Date: Wed May 15 14:59:10 2019 -0400
src.ctf.fs: merge all indexes to the fs_ds_group level
This problematic commit changes the `entries` fields of the `struct
ctf_fs_ds_index` from a `GArray *` to `GPtrArray * without changing the
pointer arithmetics.
This was not an error because indexing using `*.idx` files is optional
and indexing may fail back to direct packet indexing.
Solution
========
Use a local variable to store a pointer to the previous index_entry
rather than using pointer arithmetics.
Drawbacks
=========
None.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I3e5608d0359be2a447e79415517068c64f5a2817
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1637
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Fri, 5 Jul 2019 14:03:55 +0000 (10:03 -0400)]
bt2: update `pyproject.toml` following directories changes
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Iedf5db3a1a60329ce0a73f8f7d9bac544b3cf217
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1635
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Jonathan Rajotte [Thu, 4 Jul 2019 18:31:16 +0000 (14:31 -0400)]
Do not use diagnostic pragma when GCC version is lower than 4.6.0
Building on a SLES11 SP4.
gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973
bison (GNU Bison) 2.4
autoconf (GNU Autoconf) 2.69
automake (GNU automake) 1.15
GNU Make 3.81
The same would probably happen if using RHEL6 and its default compiler
since it uses GCC 4.4 [1].
The README suggest that we support GCC > 3.2.
Officially the diagnostic pragma are supported starting in 4.6. [2]
But they were present before 4.6 with limitation.
Error encountered:
integer.c: In function 'ctf_integer_read':
integer.c:271: error: #pragma GCC diagnostic not allowed inside functions
integer.c:271: error: #pragma GCC diagnostic not allowed inside functions
integer.c:271: error: #pragma GCC diagnostic not allowed inside functions
integer.c:276: error: #pragma GCC diagnostic not allowed inside functions
integer.c:276: error: #pragma GCC diagnostic not allowed inside functions
integer.c:276: error: #pragma GCC diagnostic not allowed inside functions
integer.c:282: error: #pragma GCC diagnostic not allowed inside functions
integer.c:282: error: #pragma GCC diagnostic not allowed inside functions
integer.c:282: error: #pragma GCC diagnostic not allowed inside functions
integer.c:287: error: #pragma GCC diagnostic not allowed inside functions
integer.c:287: error: #pragma GCC diagnostic not allowed inside functions
integer.c:287: error: #pragma GCC diagnostic not allowed inside functions
[1] https://access.redhat.com/solutions/19458
[2] https://gcc.gnu.org/gcc-4.6/changes.html
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: Ie6e4e8bd631f7aab1435fece929621c9a11990e4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1630
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Jonathan Rajotte [Thu, 4 Jul 2019 18:28:49 +0000 (14:28 -0400)]
Missing define when not building with gcc
Error encountered:
../../../../../src/compat/bitfield.h:471:2: error: unknown type name ‘_BT_DIAG_IGNORE_TYPE_LIMITS’; did you mean ‘_BT_DIAG_IGNORE’?
_BT_DIAG_IGNORE_TYPE_LIMITS \
^
../../../../../src/compat/bitfield.h:535:2: note: in expansion of macro ‘_bt_bitfield_read_be’
_bt_bitfield_read_be(ptr, unsigned char, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:473:3: note: in expansion of macro ‘bt_bitfield_read_be’
bt_bitfield_read_be(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:472:2: error: conflicting types for ‘_is_signed_type’
_is_signed_type = _bt_is_signed_type(__typeof__(_v)); \
^
../../../../../src/compat/bitfield.h:535:2: note: in expansion of macro ‘_bt_bitfield_read_be’
_bt_bitfield_read_be(ptr, unsigned char, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:473:3: note: in expansion of macro ‘bt_bitfield_read_be’
bt_bitfield_read_be(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:458:7: note: previous declaration of ‘_is_signed_type’ was here
bool _is_signed_type; \
^
../../../../../src/compat/bitfield.h:535:2: note: in expansion of macro ‘_bt_bitfield_read_be’
_bt_bitfield_read_be(ptr, unsigned char, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:473:3: note: in expansion of macro ‘bt_bitfield_read_be’
bt_bitfield_read_be(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:399:2: error: unknown type name ‘_BT_DIAG_IGNORE_TYPE_LIMITS’; did you mean ‘_BT_DIAG_IGNORE’?
_BT_DIAG_IGNORE_TYPE_LIMITS \
^
../../../../../src/compat/bitfield.h:532:2: note: in expansion of macro ‘_bt_bitfield_read_le’
_bt_bitfield_read_le(ptr, type, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:476:3: note: in expansion of macro ‘bt_bitfield_read_le’
bt_bitfield_read_le(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:400:2: error: conflicting types for ‘_is_signed_type’
_is_signed_type = _bt_is_signed_type(__typeof__(_v)); \
^
../../../../../src/compat/bitfield.h:532:2: note: in expansion of macro ‘_bt_bitfield_read_le’
_bt_bitfield_read_le(ptr, type, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:476:3: note: in expansion of macro ‘bt_bitfield_read_le’
bt_bitfield_read_le(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:386:7: note: previous declaration of ‘_is_signed_type’ was here
bool _is_signed_type; \
^
../../../../../src/compat/bitfield.h:532:2: note: in expansion of macro ‘_bt_bitfield_read_le’
_bt_bitfield_read_le(ptr, type, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:476:3: note: in expansion of macro ‘bt_bitfield_read_le’
bt_bitfield_read_le(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
bfcr.c: In function ‘read_signed_bitfield’:
../../../../../src/compat/bitfield.h:471:2: error: unknown type name ‘_BT_DIAG_IGNORE_TYPE_LIMITS’; did you mean ‘_BT_DIAG_IGNORE’?
_BT_DIAG_IGNORE_TYPE_LIMITS \
^
../../../../../src/compat/bitfield.h:535:2: note: in expansion of macro ‘_bt_bitfield_read_be’
_bt_bitfield_read_be(ptr, unsigned char, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:492:3: note: in expansion of macro ‘bt_bitfield_read_be’
bt_bitfield_read_be(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:472:2: error: conflicting types for ‘_is_signed_type’
_is_signed_type = _bt_is_signed_type(__typeof__(_v)); \
^
../../../../../src/compat/bitfield.h:535:2: note: in expansion of macro ‘_bt_bitfield_read_be’
_bt_bitfield_read_be(ptr, unsigned char, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:492:3: note: in expansion of macro ‘bt_bitfield_read_be’
bt_bitfield_read_be(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:458:7: note: previous declaration of ‘_is_signed_type’ was here
bool _is_signed_type; \
^
../../../../../src/compat/bitfield.h:535:2: note: in expansion of macro ‘_bt_bitfield_read_be’
_bt_bitfield_read_be(ptr, unsigned char, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:492:3: note: in expansion of macro ‘bt_bitfield_read_be’
bt_bitfield_read_be(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:399:2: error: unknown type name ‘_BT_DIAG_IGNORE_TYPE_LIMITS’; did you mean ‘_BT_DIAG_IGNORE’?
_BT_DIAG_IGNORE_TYPE_LIMITS \
^
../../../../../src/compat/bitfield.h:532:2: note: in expansion of macro ‘_bt_bitfield_read_le’
_bt_bitfield_read_le(ptr, type, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:495:3: note: in expansion of macro ‘bt_bitfield_read_le’
bt_bitfield_read_le(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:400:2: error: conflicting types for ‘_is_signed_type’
_is_signed_type = _bt_is_signed_type(__typeof__(_v)); \
^
../../../../../src/compat/bitfield.h:532:2: note: in expansion of macro ‘_bt_bitfield_read_le’
_bt_bitfield_read_le(ptr, type, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:495:3: note: in expansion of macro ‘bt_bitfield_read_le’
bt_bitfield_read_le(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
../../../../../src/compat/bitfield.h:386:7: note: previous declaration of ‘_is_signed_type’ was here
bool _is_signed_type; \
^
../../../../../src/compat/bitfield.h:532:2: note: in expansion of macro ‘_bt_bitfield_read_le’
_bt_bitfield_read_le(ptr, type, start, length, vptr)
^~~~~~~~~~~~~~~~~~~~
bfcr.c:495:3: note: in expansion of macro ‘bt_bitfield_read_le’
bt_bitfield_read_le(buf, uint8_t, at, field_size, v);
^~~~~~~~~~~~~~~~~~~
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: Ie9438e87c69f21ad4062b277d26ee09551ae4c97
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1629
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Jonathan Rajotte [Thu, 4 Jul 2019 21:27:29 +0000 (17:27 -0400)]
Assign *_STATUS_OK to ret
pretty.c:227 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
This *could* happen if next_status is BT_MESSAGE_ITERATOR_NEXT_STATUS_OK
and count is still 0.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I4a08d1bcc2f9b56e225ca17a210a4597169ed746
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1634
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 4 Jul 2019 07:04:20 +0000 (03:04 -0400)]
Fix: sink.text.pretty: support unknown event class name
An event class's name property is optional. Add support in
`sink.text.pretty` for a nonexistent event class name. The component
prints `<unknown>`, the same way it prints this for an enumeration field
value without a corresponding mapping.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I26740a254956534d0a47b3760456314466afc4d7
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1623
Tested-by: jenkins <jenkins@lttng.org>
Michael Jeanson [Thu, 4 Jul 2019 14:40:41 +0000 (10:40 -0400)]
tests: Remove stale tests launcher
Those 2 unused test launcher scripts were accidentaly commited when the
test suite was reworked.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Iadcddf7b91acd021298bee68d14985924f3244b8
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1625
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Jonathan Rajotte [Wed, 3 Jul 2019 21:02:59 +0000 (17:02 -0400)]
tests: Add ".exe" when running on a mingw system
libtool wrapper fail to resolve executable without ".exe" suffix on
mingw system.
tests/ctf-writer/test_ctf_writer:
babeltrace2:./.libs/lt-babeltrace2.c:237: FATAL: couldn't find ./../utils/../../src/cli/babeltrace2.
not ok 325 - Babeltrace could read the resulting trace
Change-Id: I4e916077925b34745e6b70d14d86e263427d081e
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1611
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Jonathan Rajotte [Wed, 3 Jul 2019 21:46:45 +0000 (17:46 -0400)]
Fix: log_level usage on mingw platform
The mingw build was simply broken.
For example:
mman.c: In function 'mmap_lock':
mman.c:29:30: error: 'mapping' undeclared (first use in this function)
29 | #define BT_LOG_OUTPUT_LEVEL (mapping->log_level)
| ^~~~~~~
../../src/logging/log.h:165:31: note: in expansion of macro 'BT_LOG_OUTPUT_LEVEL'
165 | #define _BT_LOG_OUTPUT_LEVEL BT_LOG_OUTPUT_LEVEL
| ^~~~~~~~~~~~~~~~~~~
../../src/logging/log.h:671:38: note: in expansion of macro '_BT_LOG_OUTPUT_LEVEL'
671 | (BT_LOG_ENABLED((lvl)) && (lvl) >= _BT_LOG_OUTPUT_LEVEL)
| ^~~~~~~~~~~~~~~~~~~~
../../src/logging/log.h:835:9: note: in expansion of macro 'BT_LOG_ON'
835 | if (BT_LOG_ON(lvl)) \
| ^~~~~~~~~
../../src/logging/log.h:974:4: note: in expansion of macro 'BT_LOG_WRITE'
974 | BT_LOG_WRITE(BT_LOG_FATAL, _BT_LOG_TAG, __VA_ARGS__)
| ^~~~~~~~~~~~
../../src/logging/log.h:995:24: note: in expansion of macro 'BT_LOGF'
995 | #define BT_LOGF_STR(s) BT_LOGF("%s", (s))
| ^~~~~~~
mman.c:122:3: note: in expansion of macro 'BT_LOGF_STR'
122 | BT_LOGF_STR("Failed to acquire mmap_mutex.");
| ^~~~~~~~~~~
mman.c:29:30: note: each undeclared identifier is reported only once for each function it appears in
29 | #define BT_LOG_OUTPUT_LEVEL (mapping->log_level)
| ^~~~~~~
../../src/logging/log.h:165:31: note: in expansion of macro 'BT_LOG_OUTPUT_LEVEL'
165 | #define _BT_LOG_OUTPUT_LEVEL BT_LOG_OUTPUT_LEVEL
| ^~~~~~~~~~~~~~~~~~~
../../src/logging/log.h:671:38: note: in expansion of macro '_BT_LOG_OUTPUT_LEVEL'
671 | (BT_LOG_ENABLED((lvl)) && (lvl) >= _BT_LOG_OUTPUT_LEVEL)
| ^~~~~~~~~~~~~~~~~~~~
../../src/logging/log.h:835:9: note: in expansion of macro 'BT_LOG_ON'
835 | if (BT_LOG_ON(lvl)) \
| ^~~~~~~~~
../../src/logging/log.h:974:4: note: in expansion of macro 'BT_LOG_WRITE'
974 | BT_LOG_WRITE(BT_LOG_FATAL, _BT_LOG_TAG, __VA_ARGS__)
| ^~~~~~~~~~~~
../../src/logging/log.h:995:24: note: in expansion of macro 'BT_LOGF'
995 | #define BT_LOGF_STR(s) BT_LOGF("%s", (s))
| ^~~~~~~
mman.c:122:3: note: in expansion of macro 'BT_LOGF_STR'
122 | BT_LOGF_STR("Failed to acquire mmap_mutex.");
| ^~~~~~~~~~~
mman.c: In function 'mmap_unlock':
mman.c:29:30: error: 'mapping' undeclared (first use in this function)
29 | #define BT_LOG_OUTPUT_LEVEL (mapping->log_level)
| ^~~~~~~
../../src/logging/log.h:165:31: note: in expansion of macro 'BT_LOG_OUTPUT_LEVEL'
165 | #define _BT_LOG_OUTPUT_LEVEL BT_LOG_OUTPUT_LEVEL
| ^~~~~~~~~~~~~~~~~~~
../../src/logging/log.h:671:38: note: in expansion of macro '_BT_LOG_OUTPUT_LEVEL'
671 | (BT_LOG_ENABLED((lvl)) && (lvl) >= _BT_LOG_OUTPUT_LEVEL)
| ^~~~~~~~~~~~~~~~~~~~
../../src/logging/log.h:835:9: note: in expansion of macro 'BT_LOG_ON'
835 | if (BT_LOG_ON(lvl)) \
| ^~~~~~~~~
../../src/logging/log.h:974:4: note: in expansion of macro 'BT_LOG_WRITE'
974 | BT_LOG_WRITE(BT_LOG_FATAL, _BT_LOG_TAG, __VA_ARGS__)
| ^~~~~~~~~~~~
../../src/logging/log.h:995:24: note: in expansion of macro 'BT_LOGF'
995 | #define BT_LOGF_STR(s) BT_LOGF("%s", (s))
| ^~~~~~~
mman.c:131:3: note: in expansion of macro 'BT_LOGF_STR'
131 | BT_LOGF_STR("Failed to release mmap_mutex.");
| ^~~~~~~~~~~
mman.c: At top level:
mman.c:173:7: error: conflicting types for 'bt_mmap'
173 | void *bt_mmap(void *addr, size_t length, int prot, int flags, int fd,
| ^~~~~~~
In file included from mman.c:53:
../../src/compat/mman.h:48:7: note: previous declaration of 'bt_mmap' was here
48 | void *bt_mmap(void *addr, size_t length, int prot, int flags, int fd,
| ^~~~~~~
mman.c: In function 'bt_mmap':
mman.c:202:12: error: too many arguments to function 'mapping_create'
202 | mapping = mapping_create(log_level);
| ^~~~~~~~~~~~~~
mman.c:73:22: note: declared here
73 | struct mmap_mapping *mapping_create(void)
| ^~~~~~~~~~~~~~
make[2]: *** [Makefile:501: mman.lo] Error 1
Change-Id: I71b36504541382cadf09953d9e113adc6c3641b6
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1610
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Wed, 3 Jul 2019 19:46:14 +0000 (15:46 -0400)]
tests: add python plugin provider path to lib search path
I am working on a test that uses a component class implemented in a
Python plugin. For it to work, babeltrace therefore needs to be able to
load the python plugin provider lib. It currently isn't found:
LIB/PLUGIN init_python_plugin_provider@plugin.c:84 Loading Python plugin provider module.
LIB/PLUGIN init_python_plugin_provider@plugin.c:94 Cannot open `libbabeltrace2-python-plugin-provider.so`: libbabeltrace2-python-plugin -provider.so: cannot open shared object file: No such file or directory: continuing without Python plugin support.
This patch makes run_python_bt2 add the right path to LD_LIBRARY_PATH
(PATH on Windows) so that babeltrace can load python plugins.
With this added we don't need the feature of run_python_bt2 and
run_python_bt2 that allowed to append an additional directory to
LD_LIBRARY_PATH, so it is removed.
Change-Id: Ie72f59c9ef4866c7f0eae0e6f49025d2fa1ba127
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1608
CI-Build: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Thu, 6 Jun 2019 20:59:44 +0000 (16:59 -0400)]
Fix: trimmer: use regexes to parse dates and times
This patch fixes a few issues related to how the trimmer component
parses timestamps.
1. Less than 9 digits in the nanoseconds position is not interpreted
correctly.
Passing "2019-01-02 12:34:56.444", we expect the nanosecond portion
to mean 444 ms, or
444000000 ns. Currently, it is interpreted as 444
ns.
2. We wrongfully accept missing digits in the various fields
It is currently possible to pass a date as "2019-1-2" (instead of
"2019-01-02") or a time as "1:2:3" (instead of "01:02:03"). This
patch makes the parsing stricter, in order to only accept the right
number of digits when parsing dates (in the form "YYYY-MM-DD") and
times (in the form "HH:MM:SS"). The nanosecond portion, if present,
can contain anywhere from 1 to 9 digits.
Change-Id: Ie315cec0bc7387ecdaa999d6c5f82f70035412f3
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1389
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Wed, 3 Jul 2019 15:40:49 +0000 (11:40 -0400)]
tests: Use diff -u
We are all more used to "unified" diff output formats than other
formats, so I suggest we use that for differences between expected and
actual results.
Change-Id: I681fcd232459eedf9c084514ca9d54be9732adcc
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1601
Reviewed-by: Jonathan Rajotte Julien <jonathan.rajotte-julien@efficios.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: Michael Jeanson <mjeanson@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Wed, 3 Jul 2019 18:30:55 +0000 (14:30 -0400)]
Fix compiler -Wall warnings (mostly incompatible enumerations)
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I399b4f8d69d116e057e4b7c89ae758744ec3f5a9
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1605
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Wed, 3 Jul 2019 18:20:02 +0000 (14:20 -0400)]
trimmer: remove unused function
Change-Id: Ic77198b4d94673dd97b63a5d042ca50e5b292081
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1604
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Wed, 3 Jul 2019 17:00:01 +0000 (13:00 -0400)]
Add back (adapted) `test_bt_values` and `test_graph_topo`
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: If030ce3688e94162060ed5d220449bf3f7895c6a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1603
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Tue, 2 Jul 2019 21:16:27 +0000 (17:16 -0400)]
Allow only TRACE, DEBUG, and INFO as the build-time, minimal log level
As there's no noticeable performance difference between having the INFO
log level and the FATAL log level as the build's minimal log level,
force it to be TRACE, DEBUG, or INFO. This means that INFO, WARN, ERROR,
and FATAL logging is always enabled, whatever the build configuration.
This seems reasonable and could prove useful to support/debugging
operations.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ie4261fd16d344587ef4b37ea1715d7302ad25087
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1590
Philippe Proulx [Sun, 30 Jun 2019 06:26:38 +0000 (02:26 -0400)]
lib: strictly type function return status enumerations
Rigour strikes again.
This patch makes each function (or group of related functions) of the
library which returns a status enumeration return its own,
function-specific status enumeration.
For example, where bt_graph_run() used to return the generic
`bt_graph_status` type, it now returns `bt_graph_run_status`.
The benefits are:
* Each function defines its own set of available status codes. With
appropriate compiler warnings, you can catch comparisons between a
returned status and an incompatible enumerator, and assignments of
incompatible enumerators. For example, with clang 8:
file.c:13:13: warning: implicit conversion from enumeration type
'enum bt_component_class_init_method_status'
to different enumeration type
'enum bt_component_class_port_connected_method_status'
[-Wenum-conversion]
bt_component_class_port_connected_method_status status =
BT_COMPONENT_CLASS_INIT_METHOD_STATUS_ERROR;
This was not possible before because all the status-returning
functions of a given header could possibly return any value defined by
the header-wide status enumeration.
* A function's possible return values are self-documented: there's no
need to document that a given function can only return some subset of
the header-wide status enumerators.
* In future minor releases of Babeltrace 2, we can add new status codes
for a specific function.
* Some smart IDEs will list the possible enumerators when checking the
return value of a function or when returning a value from a function.
To uniformize the status enumerator integer values, the new
`<babeltrace2/func-status.h>` public header contains definitions for all
the possible status codes. They are definitions instead of enumerators
because they are not meant to be used directly by user code.
To make sure a user does not write:
#include <babeltrace2/func-status.h>
to use the `__BT_FUNC_STATUS_*` definitions directly (which would
inhibit the precious type checking that this patch is all about), the
compiler will show the error:
> Do NOT include <babeltrace2/func-status.h> in user code.
unless you define `__BT_FUNC_STATUS_ENABLE` before including the header.
Each public header which needs `__BT_FUNC_STATUS_*` definitions to
define its own status enumerations does:
/* For __BT_FUNC_STATUS_* */
#define __BT_FUNC_STATUS_ENABLE
#include <babeltrace2/func-status.h>
#undef __BT_FUNC_STATUS_ENABLE
at the beginning of the file, and:
#include <babeltrace2/undef-func-status.h>
at the end of the file. The `<babeltrace2/undef-func-status.h>` header
cancels all the existing `__BT_FUNC_STATUS_*` definitions so that they
are not available to user code.
Within the library, `"lib/func-status.h"` uses the definitions of
`<babeltrace2/func-status.h>` to define its own, similar definitions,
but without the `__` prefix for improved internal code readability.
Internal library code does not need to "undefine" those definitions.
As this system guarantees that any public status enumerator is an alias
of one of the `__BT_FUNC_STATUS_*` definitions, the library code never
uses the function-specific status enumerators directly: it always uses
one of the `BT_FUNC_STATUS_*` definitions found in
`"lib/func-status.h"`. This made it easier to adapt existing code. This
also allows to pass such status codes easily between internal and public
functions because they are `int` values until they finally reach public
enumeration types where they are implicitly casted.
When an internal (hidden, static) function returns a status code, it now
returns `int`, using one of the `BT_FUNC_STATUS_*` values, where this
could be used by at least two functions returning different public
status enumerations.
In internal headers, all the bt_*_status_string() are removed in favor
of bt_common_func_status_string() which returns only the suffix string
(e.g., `OK`, `ERROR`, `OVERFLOW`). This function is typically used when
logging.
The `*_NOMEM` enumerators are renamed to `*_MEMORY_ERROR` to make this
clear and remove this abbreviation which was the only one amongst other
public status enumerators.
Because the Python bindings are within the Babeltrace project, they use
the `__BT_FUNC_STATUS_*` definitions internally. Those values will not
change in the future anyway. All the _handle_*status() and
bt2.utils._handle_ret() functions are removed in favor of
bt2.utils._handle_func_status() which can handle all the possible status
codes and raise a corresponding exception, possibly with a given
message.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I3966ac0e691219102897920617711c518c34fbdf
Philippe Proulx [Tue, 2 Jul 2019 19:34:42 +0000 (15:34 -0400)]
tests/lib: remove `test_bt_values` and `test_graph_topo`
What those programs test is already tested by the thorough Python
bindings tests.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I89fe31e7f087bc317ff93861fd3dc257b2b00bf0
Philippe Proulx [Wed, 3 Jul 2019 01:26:25 +0000 (21:26 -0400)]
Fix: bt_packet_context_field_create(): remove "frozen" SC precondition
In bt_packet_context_field_create(), it is not a precondition that the
stream class be frozen. It used to mean that the stream class was
previously added to a trace class, but this is always the case now that
you pass the trace class to bt_stream_class_create().
bt_packet_context_field_create() freezes the stream class on success.
This shows that you can call bt_packet_context_field_create() with a
fresh, hot stream class, and then it becomes frozen.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I7487a516344d8b666e17d1c5e1a7dcefd1fd182e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1591
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Sat, 29 Jun 2019 16:30:09 +0000 (12:30 -0400)]
test_{field,value}.py: array test cases: add non-sequence equality tests
The new tests verify that an array field or an array value is not equal
to another iterable object which would provide the correct element
values, but which is not a `collections.abc.Sequence`. This is similar
to how
[1, 3, 5] == collections.OrderedDict([(1, 2), (3, 4), (5, 6)])
is false.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: If7402e4f0e747d2c9d17ddb5ce7aa4fc4156314d
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1588
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Sat, 29 Jun 2019 16:16:38 +0000 (12:16 -0400)]
test_{field,value}.py: test complex number RHS for binary operations
This patch adds injected tests for numeric field and value test cases in
which the RHS operand of the tested binary operations is a complex
number, both `-23+19j` and `0j`.
This is to ensure that a binary operator applied to a field object or a
value object and a Python complex number returns what's expected by the
langage, so you can do:
print(my_field + 8+4.2j)
if you wish.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5cade062e285752d0a917a8b751824b0ebc97f16
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1587
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Sat, 29 Jun 2019 16:04:41 +0000 (12:04 -0400)]
test_value.py: make `BoolValueTestCase` inherit `_TestNumericValue`
`BoolValue` is a numeric value, so `BoolValueTestCase` can inherit
`_TestNumericValue` and get more tests.
_inject_numeric_testing_methods() is also called on `BoolValueTestCase`
to test the different unary and binary operators.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I8fff73a0dda1e9ec9f6737739dde255c9b079ebf
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1586
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Sat, 29 Jun 2019 15:41:36 +0000 (11:41 -0400)]
test_value.py: _inject_numeric_testing_methods(): remove `has_neg`
This was only required for "self", __i*__() operators, which needed to
modify the value object. For example, you couldn't do:
u = bt2.UnsignedIntegerValue(34)
u -= 100
because the assignment in __isub__() had an invalid value.
Now the __i*__() operators do not exist anymore, so all RHS negative
values work.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib2217150bd5c90b2ab72e5ed3b02c5d5206a22c3
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1585
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Sat, 29 Jun 2019 15:28:34 +0000 (11:28 -0400)]
test_{field,value}.py: add comments
Those files contain code which is very similar. It should be a single
helper base class eventually, but this patch only adds comments to both
files to clarify the usage of some classes and methods.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I15d8d4e1d8d3444491b9f01deb6d2cdcc5d406d1
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1584
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 05:16:21 +0000 (01:16 -0400)]
bt2: create_value(): check `numbers` and `collections.abc` types
This is just like what's done within _NumericValue._extract_value(),
_IntegerValue._value_to_int(), RealValue._value_to_float(),
StringValue._value_to_str(), ArrayValue.__eq__(), and MapValue.__eq__().
It is more versatile than checking for the specific built-in types.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I93902e58b6adf3f9cd5c03c7c422148d577b5f0f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1571
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 05:12:11 +0000 (01:12 -0400)]
bt2: _ArrayField.__setitem__(): do not check type
There's no need to check the type of the parameter because
field.value = value
will raise a type error if `value` has an unexpected type.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I0ae91873024e9a52a00bb1ac6f03ff830a19dea7
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1570
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 05:08:25 +0000 (01:08 -0400)]
bt2: field.py: _value_to_int(): require `numbers.Integral`
Be more strict in the _value_to_int() functions: require that the
parameter's type is an instance of `numbers.Integral` instead of
`numbers.Real` to make the following raise a type error:
my_int_field.value = 17.5
I believe it's better to be strict here than to arbitrarily choose to
use the parameter's value's floor.
RealValue._value_to_float() already requires a real value, so this is
just analogous.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I3b981e90f7e2c133fa4d56e79333c4fe600eca8b
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1569
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 05:03:18 +0000 (01:03 -0400)]
bt2: field.py: numeric classes: remove __i*__ operators
Those operators do a binary operation to a field object and another
operand, and then set the result as the field object's value.
Now that I think about it, it is weird to do something like:
my_int_field += 17.5
and that, when the value of `my_int_field` was 23, its value after the
operation becomes 40. This is not a problem for a native Python object
because `a` does not name the same object after the operation:
a = 23
type(a) # int
id(a) #
140669243488160
a += 17.5
type(a) # float
id(a) #
140669043054920
but we can't do this with our field object: this is internal Python's
magic.
So I believe we should be more strict. But this means you can't do:
my_int_field += 17.5
anymore (a `TypeError` exception would be raised).
This means a lot of specific automatically injected tests must
conditionally exist (depending on whether or not the test is possible
with the two operands, whereas it's always possible now).
Instead of doing this work, I choose to completely remove the support
for "self" operators. We can add useful ones in the future when we have
time, but I don't even think they are super useful: because a field
object becomes conceptually frozen as soon as you emit a message which
owns it indirectly, there's no point in doing `+=`, `-=`, `**=`, `<<=`,
and so on. For those rare cases, you can always do:
my_int_field = my_int_field + 17
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5410ff8fdb2c3a1910e788542376d521601fdf8f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1568
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 04:44:04 +0000 (00:44 -0400)]
bt2: value.py: _IntegerValue._value_to_int(): require `numbers.Integral`
Be more strict in _IntegerValue._value_to_int(): require that the
parameter's type is an instance of `numbers.Integral` instead of
`numbers.Real` to make the following raise a type error:
bt2.UnsignedIntegerValue(17.5)
and
a = bt2.UnsignedIntegerValue()
a.value = 17.5
I believe it's better to be strict here than to arbitrarily choose to
use the parameter's value's floor.
BoolValue._value_to_bool() and RealValue._value_to_float() already
require resp. a boolean value and a real value, so this is just
analogous.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I374baf8c5d69400b687daabea873598eb2543a47
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1567
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 04:32:14 +0000 (00:32 -0400)]
bt2: value.py: numeric classes: remove __i*__ operators
Those operators do a binary operation to a value object and another
operand, and then set the result as the value object's value.
Now that I think about it, it is weird to do something like:
a = bt2.UnsignedIntegerValue(23)
a += 17.5
and that the value of `a` becomes 40. This is not a problem for a native
Python object because `a` does not name the same object after the
operation:
a = 23
type(a) # int
id(a) #
140669243488160
a += 17.5
type(a) # float
id(a) #
140669043054920
but we can't do this with our value object: this is internal Python's
magic.
So I believe we should be more strict. But this means you can't do:
a = bt2.UnsignedIntegerValue(23)
a += 17.5
anymore (a `TypeError` exception would be raised).
This means a lot of specific automatically injected tests must
conditionally exist (depending on whether or not the test is possible
with the two operands, whereas it's always possible now).
Instead of doing this work, I choose to completely remove the support
for "self" operators. We can add useful ones in the future when we have
time, but I don't even think they are super useful: because a value
object becomes conceptually frozen as soon as you use it somehow,
there's no point in doing `+=`, `-=`, `**=`, `<<=`, and so on. For those
rare cases, you can always do:
a = bt2.UnsignedIntegerValue(23)
a = a + 17
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Icd5f0a9d0232c2f7ba91133561235fec7526083b
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1566
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 04:02:01 +0000 (00:02 -0400)]
bt2: make `BoolValue` inherit `_IntegralValue`
This is just like
issubclass(bool, numbers.Integral)
issubclass(bool, int)
are true.
It makes `BoolValue` behave even more like `bool`, for example you can
now do:
3 << bt2.BoolValue(True)
(which is 6).
Also remove BoolValue.__eq__() because _NumericValue.__eq__() does the
job now.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Icbcd8d41b9f064c77586e0b7bfdf4a772c15f0f7
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1565
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 03:54:08 +0000 (23:54 -0400)]
bt2: field.py: refactor field comparison
Changed:
* In _NumericField._extract_value(), do not check the `False`, and
`True` special cases: check that the parameter is an instance of the
`bool` type to return a boolean object.
* In _ArrayField.__eq__(), be more strict: expect that the parameter is
a sequence object, not just an iterable object. Before this, it was
possible to compare an array field to an ordered dict with keys equal
to the array field content, and this seems wrong as:
collections.OrderedDict((('A', 23), ('B', 42))) == ['A', 'B']
is false. An ordered dict is not a sequence.
* In _StructureField.__eq__(), be more strict: expect that the parameter
is a mapping object, not just an iterable and indexable object. The
reason is similar to the _ArrayField.__eq__() case above. This should
be enough to compare to another structure field or to a dict (or
ordered dict).
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I17f33c24e9dea526e59b5058235d57facb51cfbf
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1564
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 03:51:24 +0000 (23:51 -0400)]
bt2: value.py: refactor value comparison
Changed:
* Remove _spec_eq() methods: each class implements its own __eq__()
method directly.
* Do not use native_bt.value_compare(): we never reached that, because
container value classes (`ArrayValue` and `MapValue`) implement their
own rich, recursive comparison.
* In _NumericValue._extract_value(), do not check the `_NumericValue`,
`False`, and `True` special case: check for `BoolValue` and `bool` to
return a boolean object in those cases.
* In NumericValue.__lt__() and NumericValue.__eq__(), do not check that
the parameter is a number object: self._extract_value() does this
already.
* In BoolValue._value_to_bool(), return the boolean value directly,
not using int(): it's already an integral number.
* In ArrayValue.__eq__(), be more strict: expect that the parameter is
a sequence object, not just an iterable object. Before this, it was
possible to compare an array value to an ordered dict with keys equal
to the array value content, and this seems wrong as:
collections.OrderedDict((('A', 23), ('B', 42))) == ['A', 'B']
is false. An ordered dict is not a sequence.
* In MapValue.__eq__(), be more strict: expect that the parameter is a
mapping object, not just an iterable and indexable object. The reason
is similar to the ArrayValue.__eq__() case above. This should be
enough to compare to another map value or to a dict (or ordered dict).
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I9941d2d82942e2efa8d5380c8ff5a4a2d2cb3a84
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1563
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Fri, 28 Jun 2019 03:39:21 +0000 (23:39 -0400)]
bt2: make `_ArrayField` inherit `collections.abc.MutableSequence`
An array field is conceptually a mutable sequence just like an array
value (`ArrayValue`).
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ia3f27fd524286e924b5529030963df33e7553336
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1562
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Thu, 27 Jun 2019 03:33:58 +0000 (23:33 -0400)]
bt2: let Python message iterators implement seek beginning
This patch adds the possibility for message iterators implemented in
Python to implement the "can seek beginning" and "seek beginning"
operations.
A message iterator can support "seek beginning" by defining a
_seek_beginning method:
class MyIter(bt2._UserMessageIterator):
def _seek_beginning(self):
# Do the needful.
It can support the "can seek beginning" operation by defining a
_can_seek_beginning property, which must evaluate to a bool:
class MyIter(bt2._UserMessageIterator):
@property
def _can_seek_beginning(self):
# Do the needful, including returning a bool.
The behavior of the "can seek beginning" operation is made to mimic
the C API:
- If the iterator has a _can_seek_beginning attribute, it is used to
determine whether the iterator can seek beginning.
- Otherwise, the presence or absence of a _seek_beginning method
indicates whether it can.
Change-Id: I68c48b5cd30090bff833529cda9fa918c7e72b0b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1555
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 28 Jun 2019 21:03:27 +0000 (17:03 -0400)]
lib: internal: message.h: require logging
This patch makes the internal `message.h` require what it needs instead
of using the macros only if they exist. This makes it impossible to skip
logging in this header.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2dd300931479a1d0752b6f90079c826324e19ce1
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1581
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 21:01:51 +0000 (17:01 -0400)]
lib: internal: object-pool.h: require logging
This patch makes the internal `object-pool.h` require what it needs
instead of using the macros only if they exist. This makes it impossible
to skip logging in this header.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5f1b5550dfca7c7f3e8d62134a2917b059e4da0c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1580
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 21:01:10 +0000 (17:01 -0400)]
Fix: CTF writer: include CTF writer (own) version of `object-pool.h`
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I9261eea60e71e85b56b1abe6bd21d1eb4ebfdeab
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1579
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 20:55:38 +0000 (16:55 -0400)]
lib: internal: clock-snapshot-set.h: require logging
This patch makes the internal `clock-snapshot-set.h` require what it
needs instead of using the macros only if they exist. This makes it
impossible to skip logging in this header.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib8b3def2869ab214a3d38e3a1cea7b9954fc056c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1578
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 20:52:42 +0000 (16:52 -0400)]
lib: internal: graph.h: require logging and BT_ASSERT_{PRE,POST}()
This patch makes the internal `graph.h` require what it needs instead of
using the macros only if they exist. This makes it impossible to skip
logging or precondition/postcondition validation in this header.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I157809be7b56720b2f4a241c45491413f5b8366d
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1577
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 20:45:01 +0000 (16:45 -0400)]
lib: internal: define `BT_ASSERT_{PRE,POST}_SUPPORTED` in headers
This is to make some headers require that precondition and postcondition
assertion macros exist when including them, just like
`src/lib/logging.h` defines `BT_LIB_LOG_SUPPORTED` for the same reason.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ia2db609ae540b29129b9260c237f8b8d9657d977
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1576
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 20:44:25 +0000 (16:44 -0400)]
lib: internal: replace BT_ASSERT_PRE* -> BT_ASSERT_POST* where applicable
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I8acc12b771a7d4040bc136d5860311fc7646295f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1575
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Fri, 28 Jun 2019 19:55:56 +0000 (15:55 -0400)]
lib: internal: add BT_ASSERT_POST()
BT_ASSERT_POST() is just like BT_ASSERT_PRE(), but it is used to
validate the returned values of user functions and methods.
The only difference with BT_ASSERT_PRE() is that its error message
indicates that a postcondition was not satisfied instead of a
precondition. This is simply more accurate.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I91815301ada19b42ba58f32db7b9c412cbe641e0
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1574
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Thu, 27 Jun 2019 16:24:23 +0000 (12:24 -0400)]
Add `src/py-common`, containing bt_py_common_format_exception() for now
This new convenience library is meant to contain functions used by
Python bindings and the Python plugin provider.
As of this patch, it only offers bt_py_common_format_exception(), which
is similar to what bt2_py_loge_exception() used to do in
`native_bt_component_class.i`, except that it returns the formatted
exception string instead of logging it directly. Now
bt2_py_loge_exception() uses bt_py_common_format_exception().
bt_py_common_format_exception() will be needed in a future patch to set
the message of an error cause when appending from the Python plugin
provider.
No functional change intended.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Iaa9dc081e7d8a3d6c85420fcbbfc045a9d79bf27
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1556
Tested-by: jenkins <jenkins@lttng.org>
Michael Jeanson [Fri, 28 Jun 2019 20:01:56 +0000 (16:01 -0400)]
fix: don't use realpath from GNU coreutils
Turns out 'realpath' is specific to GNU coretuils, we'll have to live
with uglier relative unresolved paths.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I7febbd12dd7f8d49c938f3fffc6db44c6dd89d6a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1573
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 17 Jun 2019 23:18:13 +0000 (19:18 -0400)]
lib: validate monotonicity of messages from upstream component
This patch adds two checks after having called an iterator's next
method, to verify the validity of what is returned.
Clock class compatibility
-------------------------
Check that the clock classes of new streams created through this
iterator are compatible with the clock classes of streams previously
created through the same iterator.
The first time a stream is created through an iterator, we save some
properties of that clock class (whether its origin is the Unix epoch,
and if it isn't, its uuid). When new streams appear, we compare those
properties to make sure the clock classes of the new streams are
compatible with those properties.
Clock snapshots increase
------------------------
Check that the clock snapshots of all messages (that have one) don't go
back in time.
For each incoming message, if it has a clock snapshot, we compare it
with the clock snapshot of the previous message and assert that it isn't
lower (the "previous message time" is initialized to INT64_MIN).
Some messages don't have a clock snapshot, for those we do nothing.
I am not considering the "infinity" value that stream activity end
messages can have. It would add a bit more complexity to validate them
propertly, because it's possible to have something like this:
Stream 1: ... EV(1) SAE(inf) SE
Stream 2: ... EV(2) EV(10) ...
As you can see, it is possible to have a finite value (10) on stream 2
after having received an SAE message at infinity on stream 1. We could,
validate that nothing with a finite clock snapshot comes on stream 1
specifically. It would however require some per-stream data, which adds
a bit of complexity. And since we plan on removing these messages
anyway, it doesn't seem to be worth the effort.
Change-Id: If18f475ed056fda77a539d700e6ad310111f6d6b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1486
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Thu, 27 Jun 2019 19:56:28 +0000 (15:56 -0400)]
Fix: bt2: fix reference counting of messages returned by Python components
The refcount of messages returned by components implemented in Python
(in _UserMessageIterator._next_from_native) is not right.
When the C iterator method "next" puts bt_message pointers in the output
array, it gives its reference to the bt_messages to the array. If it
wishes to keep owning a copy of the message, it needs to acquire a new
reference.
For this reason, we currently make the Message Python object release its
reference to the bt_message in _UserMessageIterator.__next__ (otherwise
there would be a double free). Releasing the reference has the effect
of setting the _ptr property to None, without changing the refcount.
However, it's possible for the user to keep a reference to that Python
object and re-use it. This is a problem, since the Message Python
object now unexpectedly no longer wraps a valid bt_message. Trying to
return that message in the following call to __next__, for example, will
fail.
To fix this, this patch makes _next_from_native acquire a new reference
before returning the bt_message. If the user didn't keep a reference to
the Python object, the Python object will die and put the bt_message.
The message array will therefore be the sole owner of the message. If
the user did keep a reference to the Python object, then both the Python
object and the message array will now own a reference to the message.
Change-Id: I6f7c472fddeea35509ee669e11d913bec7091f40
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1559
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Thu, 27 Jun 2019 20:03:55 +0000 (16:03 -0400)]
lib: fix compilation for glib < 2.40
Code from commit "lib: add logic in auto-seek to recreate stream state"
uses the return value of function g_hash_table_insert to validate that
the inserted key did not previously exist in the hash table. This
feature was introduced in glib 2.40, before that the function returned
void.
To avoid breaking compatibility with glib < 2.40, we can do a lookup
before inserting to achieve the same result.
Change-Id: Ibd5f58fb6ab8f083a3152105db9e05522893132c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1560
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Michael Jeanson [Mon, 17 Jun 2019 20:48:02 +0000 (16:48 -0400)]
tests: Rework test suite
* Test script are not generated by autoconf anymore, instead the
parameters are passed trought a set of environment variable prefixed
with BT_TESTS_. This will enable the test suite to be used against
a system installed version of babeltrace with minimal configuration.
* Move all duplicated shell script code to 'utils.sh'.
* Add 'set -u' to common.sh to catch undefined variables in test
scripts. Variables that are expected to be undefined must be used as
'${var:-}'.
* All shell script is shellcheck tested.
* Removed unused test 'test_trace_ir'
* The python test runner now returns an error when no python test
scripts are found.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I15dcda1d147c8c72c6e4ee00052591eb6f9e30bd
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1429
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Michael Jeanson [Thu, 27 Jun 2019 18:50:42 +0000 (14:50 -0400)]
port: Use sig_t instead of sighandler_t
The 'sighandler_t' is a GNU extension specific to Glibc, use the more
portable 'sig_t' to support macOs and others.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I0c6fd8792936c6559a8d8018b3b444559b6dc3b1
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1557
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Thu, 27 Jun 2019 23:38:59 +0000 (19:38 -0400)]
bt2: use `_extract_value()` on comparison
After further discussions, we realized that there was a better way to
address the issue that commit
7bb4180 is fixing.
The real issue was that we were unconditionally converting the `other`
object to the `complex` type even when neither objects were of the
`complex` type. This was causing problem because of the lost of
precision when storing very large integer value in a variable of
`complex` type.
The better solution is to convert both objects to the type of the wider
object, and that is what Python does automatically. To enable that, we
simply need to convert the `other` object to it's corresponding standard
numeric type [1]. This commit uses the existing `_extract_value()`
method to achieve that.
[1]: https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Ib658d1fdaf41a0ee592212a101fa4ad0ea952eb4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1561
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Tue, 25 Jun 2019 21:44:32 +0000 (17:44 -0400)]
Fix: bt2: erroneous integer comparison of Field and Value
Issue
=====
The `{Unsigned, Signed}IntegerValue` class inherit its __eq__() method
from the `_NumericValue` class. This method converts the `other` object
to a `complex` number to make the comparison as generic as possible. The
issue is that the large complex number comparison is unreliable as it's
using float comparison[1]. The timestamps we are dealing with will often
be going beyond the limit of exact comparison possible with the IEEE 754
double-precision[2].
I encountered this issue while comparing a
`bt2.value.SignedIntegerValue` to a large Python Integer representing a
timestamp in nanosecond.
Here is a showcase of the issue reproduced without the `bt2` bindings:
In [1]: 42 == complex(42)
Out[1]: True
In [2]:
1561489497327275497 == complex(
1561489497327275497)
Out[2]: False
The same issue is reproducible with the `_{Unsigned,
Signed}IntegerField`.
Solution
========
Implement the __eq__() and __lt__() methods in the `_IntegralValue`
class and but still use `_NumericValue`'s methods if the `other` object
is not an instance of `numbers.Integral`.
Implement the __eq__() and __lt__() methods in the `_IntegralField`
class and but still use `_NumericField`'s methods if the `other` object
is not an instance of `numbers.Integral`.
Drawback
========
None.
Note
====
I added test cases to cover large integer comparison for both Integer Value and
integer Field classes.
[1]: https://stackoverflow.com/questions/
5595425/what-is-the-best-way-to-compare-floats-for-almost-equality-in-python
[2]: https://en.wikipedia.org/wiki/Double-precision_floating-point_format
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I8448bd42704ad1a2d215bece8534c839b9468f25
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1538
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Francis Deslauriers [Wed, 26 Jun 2019 15:07:53 +0000 (11:07 -0400)]
bt2: remove __le__() method already provided by @total_ordering
The `@total_ordering` decorator already provide all the rich comparison
methods because we implement the __lt__() and __eq__() methods. So there
is no need to implement any other rich comparison methods.
I chose __lt__() arbitrarily but it could have been __le__(), __gt__(),
or __ge__().
Documentation on `@total_ordering` [1]:
The class must define one of __lt__(), __le__(), __gt__(), or
__ge__(). In addition, the class should supply an __eq__() method.
[1]: https://docs.python.org/3/library/functools.html#functools.total_ordering
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I4c09ae725acadc59aa17d03063136ffc0dd854c2
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1544
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Michael Jeanson [Thu, 27 Jun 2019 19:16:48 +0000 (15:16 -0400)]
fix: Use python-config 'ldflags' instead of 'libs'
This allows building the python plugin provider against a Python
installation that is not in the default system path.
The output of '--ldflags' is the same as '--libs' with the added linker
path to the python library.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Idf0171bdc181a7d6d7593021dab957437772b2f5
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1558
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 17 Jun 2019 16:58:31 +0000 (12:58 -0400)]
lib: add logic in auto-seek to recreate stream state
The trimmer component uses the seek_ns_from_origin iterator method to
seek its input iterator to the beginning of its trim window. After,
that, it's possible for the first message after the seek time to be, for
example, an event message. If so, it needs to re-create some messages
(possibly stream begin, stream activity begin and packet begin) to put
the stream in the right state. Otherwise, it would emit messages in an
invalid sequence.
A problem arises however with the following sequence:
1. The trim window starts at timestamp 50
2. Trimmer gets event message with timestamp 100 on stream 0. The
trimmer will send the following messages: stream 0 beginning, stream
0 activity beginning at timestamp 50, packet beginning message on
stream 0 at timestamp 50, event message on stream 0 at timestamp 100.
3. Trimmer gets event message with timestamp 120 on stream 1. The
trimmer will send the following messages: stream 1 beginning, stream
1 activity beginning at timestamp 50, packet beginning message on
stream 0 at timestamp 50, event message on stream 1 at timestamp 120.
The "stream 1 activity beginning at timestamp 50" message is invalid,
because it is earlier than the previously sent message "event message on
stream 0 at timestamp 100".
To avoid this going back in time, we need to emit the made up messages
first thing after seeking, instead of waiting for an event message (or
some other message requiring a stream and/or packet to be open) to emit
them. The trimmer can't do that itself, because it doesn't know the
state of the streams right after seeking (it doesn't know what messages
would have come before the seek point).
Therefore, the patch moves the functionality of emitting the missing
messages to the iterator code. When seeking (and using the go to
beginning then fast forward strategy, AKA auto-seek), the iterator code
goes through (and drops) all messages before the seek point. It can
therefore maintain a table of the state of all the streams. Once it has
reached the seek time, it can generate the messages required to bring
the streams in the state they are supposed to be, before transmitting
the messages coming from upstream.
Moving this functionality to the iterator also has the advantage that if
other components use the seek_ns_from_origin method of the iterator,
they'll receive a valid flow of messages. They won't need to do the
same complex work that the trimmer was doing to try re-create messages.
Since the trimmer can now assume a valid message flow from its input
iterator, it doesn't need anymore to generate its own stream beginning,
stream activity beginning and packet beginning messages before
transmitting a message that is supposed to come after one of these.
This means that the ensure_stream_state_is_inited and
ensure_cur_packet_exists functions can be removed.
Change-Id: I548f6ceafa5ad315c65be48077898595882e4511
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1450
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 27 Jun 2019 18:02:58 +0000 (14:02 -0400)]
Append "library" to pkg-config packages names
It looks like most pkg-config package names have "library" in them, so
have it also in our files to normalize them.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5fd111e842edf9b55daaec034763d79878db8680
Michael Jeanson [Mon, 17 Jun 2019 20:34:03 +0000 (16:34 -0400)]
Provide proper pkg-config .pc files
* Update name and description for Babeltrace2
* Remove unneeded dependency on popt
* Replace static uuid dependency with configured values
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Ie249ff75316fe6cf86f70a04b4ef80776f689f1e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1482
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 17 Jun 2019 17:01:03 +0000 (13:01 -0400)]
iterator: save original next callback in iterator struct
When we restore the iterator's next method (after we overrode it with
post_auto_seek_next), we inspect the upstream component class to find
out what was the original method. It seems simpler to save and restore
the function pointer. This is what this patch does.
No user-visible changes intended.
Change-Id: If5eb7df692d2aa745f7f19e22c8046afb5b8d1d2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1485
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 17 Jun 2019 16:56:24 +0000 (12:56 -0400)]
iterator: move auto-seek data in its own struct, add comments
Further patches will add more fields related to this feature, so it
seems useful to group them under the same (anonymous) struct.
No functional changes intended.
Change-Id: I6ed922801cf5bd9001d388d7d8b050a6c8d01790
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1484
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Michael Jeanson [Fri, 21 Jun 2019 14:57:25 +0000 (10:57 -0400)]
fix: Add missing include on macOs
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Iad3dccd64a838890f0f79039df0e008ff8e9f34a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1529
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Jonathan Rajotte [Wed, 19 Jun 2019 17:27:34 +0000 (13:27 -0400)]
tests: remove carriage return when using diff
Carriage return are a problem when running tests on cross execution
platform such as Windows. This only happen when diffing text generated
on Windows and text from a linux file.
The removal of mid-sentence '\r' is not a problem here since we do not
expect bt to generate this kind of string.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I107c5487bf3aa0f5cbd1fdfd1e948ee93f830d2f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1521
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Jonathan Rajotte [Wed, 19 Jun 2019 17:27:21 +0000 (13:27 -0400)]
libs: Do not rely on nftw for detecting the validity of plugin path
test_plugin.c:test_create_all_from_dir with non existing path fails on
cygwin. An error is expected but bt_plugin_find_all_from_dir returns
success.
The cygwin implementation of nftw is not posix compliant regarding
returning ENOENT on non-existent path. [1] [2]
The cygwin implementation of nftw does not return ENOENT on non-existent
path. Instead, the non-existent path is passed through the fn function
(nftw_append_all_from_dir) and the flag is set to FTW_NS.
Since we are "discovering" plugins, nftw_append_all_from_dir does not
error out on FTW_NS and simply skip the file.
The proposed solution is to stat() the provided path and validate that
no errors occur before using nftw().
[1] https://pubs.opengroup.org/onlinepubs/
9699919799/functions/nftw.html
[2] https://cygwin.com/ml/cygwin/2019-06/msg00185.html
Change-Id: Ia7c88dbab5b16affbdb8ce1dbe261b03635727cc
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1520
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Jonathan Rajotte [Wed, 26 Jun 2019 18:48:06 +0000 (14:48 -0400)]
Fix: return status instead of ret
Commit
9736d991ea189f29b908e9cf18103c1452c59e05 modifies the error
handling of bt_plugin_create_append_all_from_dir but fails to return the
actual status.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I147a212e1556d81a4fe9cbef839cfe65b345195c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1545
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Thu, 27 Jun 2019 02:46:08 +0000 (22:46 -0400)]
lib: rename `BABELTRACE_NO_DLCLOSE` -> `LIBBABELTRACE2_NO_DLCLOSE`
I feel like this environment variable is more about the library than
about the project as a whole, like `LIBBABELTRACE2_INIT_LOG_LEVEL`.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I19e5229fc64d54f2a4ff23ef36647ba78917b619
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1554
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Thu, 27 Jun 2019 02:01:55 +0000 (22:01 -0400)]
bt2: fix formatting of C code in native_bt_component_class.i
Change-Id: Ia1bdd2916178a2f5512e00c9ef493e642d9d25cc
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1553
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Thu, 27 Jun 2019 00:04:49 +0000 (20:04 -0400)]
cli: add missing line in --plugin-path help
When doing "babeltrace2 convert --help", a line is missing from the
--plugin-path option help. This patch adds it, copied from the help of
the other commands.
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I823385cae29afa2bfa0650d4c5dd0142dd4f9cea
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1549
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Wed, 26 Jun 2019 13:49:57 +0000 (09:49 -0400)]
lib: reverse order of bt_self_component_port_input_message_iterator::auto_seek_msgs queue
The messages in this queue are in reverse chronological order, meaning
we push the incoming messages to the head and later consume them from
the tail.
It would be more expected (although functionally equivalent) to do the
opposite, so that the messages are in chronological order when iterating
the list in forward.
So this patch just swaps the push/pop calls around.
Change-Id: Id4892e12e064376e919647c0d8bb838156ef0fc5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1543
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Tue, 25 Jun 2019 17:51:29 +0000 (13:51 -0400)]
bt2: rename native_bt_notifier.i to native_bt_message_iterator.i
We don't use the term notifier anymore, message iterator is more
contemporary.
Change-Id: Iadda98ac83a2dfddcb207d3beb99ddaa65181ad3
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1536
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Tue, 25 Jun 2019 17:22:00 +0000 (13:22 -0400)]
bt2: remove unused double* typemap
This typemap seems to be unused, remove it.
Change-Id: I06f1692f6cff224ecb164058edf87025b0d7cd35
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1535
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 21 Jun 2019 22:37:24 +0000 (18:37 -0400)]
bt2: replace copy of headers for SWIG with includes
The current approach of writing SWIG interface files is to copy paste
declarations. This can be tedious and error prone, when the API is
modified.
This patch changes the interface files to include the Babeltrace header
files containing those declarations instead.
The main difficulty with this is that we can't rely on parameter names
for typemap matching anymore. In most cases, using just the type is
fine (e.g. the only reason a function takes a
bt_self_component_port_input ** is as an output parameter).
In the case of "user data" it's a bit more tricky, since the type is
"void *". In these cases (in native_bt_component.i and
native_bt_port.i), I made it so we clear the typemap at the end of the
file, so hopefully it doesn't apply to an unexpected function in another
file.
In native_bt_field_class.i, the typemap for
(bt_field_class_enumeration_mapping_label_array *label_array, uint64_t *count)
doesn't work if I leave out the parameter names, for some reason, so I
have put the parameter names used in the headers.
Change-Id: I2e98c60c2dcb7c8ea243b4cf36e0fcfaf53e9cde
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1531
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Wed, 26 Jun 2019 19:02:28 +0000 (15:02 -0400)]
Rename `BT_LOG_LEVEL` -> `BT_MINIMAL_LOG_LEVEL`
This makes it very clear.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: If3baf92799e2d0384d9f217c66414424155bac88
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1547
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Wed, 26 Jun 2019 18:39:42 +0000 (14:39 -0400)]
Do not require logging support for BT_[CTF_]ASSERT_PRE()
This patch makes the BT_ASSERT_PRE(), BT_ASSERT_PRE_MSG(),
BT_CTF_ASSERT_PRE(), and BT_CTF_ASSERT_PRE_MSG() not use BT_LIB_LOGF()
and BT_LOGF() directly to not rely on the active log level to print the
messages.
This makes it possible to configure the build with
`BABELTRACE_DEV_MODE=1` and `BABELTRACE_MINIMAL_LOG_LEVEL=NONE` and
still get the precondition failure messages. This removes some code
in `configure.ac` and `src/lib/logging.c` which ensured that the log
level could not be NONE when developer mode is enabled.
The macros now use _bt_log_write_d() (which does not check the active
log level) and bt_lib_log() (which uses _bt_log_write_d() without
checking the active log level) instead of BT_LOGF() and BT_LIB_LOGF().
The `assert-pre.h` header still require that you include
`"lib/logging.h"` or `"logging/log.h"` before because this is where the
logging tag and logging functions are found.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: If98a1c074d211cf257742d55960b379bbe9c6cf0
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1546
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Tue, 25 Jun 2019 16:50:17 +0000 (12:50 -0400)]
lib: bt_plugin_find*(): return status code; add "fail on load error" param
The bt_plugin_find*() functions, before this patch, return a plugin
object or a plugin set object. When such a function returns `NULL`, you
have no way to tell if it's because there was an error or if no plugins
were found.
Also, when a plugin cannot be loaded for various reasons, sometimes it's
considered an error and sometimes not, so there's no way to be strict.
This patch makes:
* The bt_plugin_find*() functions return a status code, and return the
plugin or plugin set object by output parameter.
The available, new status codes are:
`BT_PLUGIN_STATUS_OK`:
Everything is fine.
`BT_PLUGIN_STATUS_NOT_FOUND`:
No plugins were found.
`BT_PLUGIN_STATUS_ERROR`:
There was a general error while trying to find plugins.
`BT_PLUGIN_STATUS_LOADING_ERROR`:
A plugin could not be loaded successfully while trying to find
plugins.
`BT_PLUGIN_STATUS_NOMEM`:
There was an allocation error while trying to find plugins.
The bt_plugin_find_all_from_file() and bt_plugin_find_all_from_dir()
never return an empty plugin set: they return
`BT_PLUGIN_STATUS_NOT_FOUND` instead.
* The bt_plugin_find*() functions accept a new `fail_on_load_error`
parameter which controls whether a plugin loading error is ignored
(can eventually lead to `BT_PLUGIN_STATUS_NOT_FOUND` being returned)
or triggers a loading error condition
(`BT_PLUGIN_STATUS_LOADING_ERROR`).
When `fail_on_load_error` is true, the functions log errors with
the WARN level. When it's false, they log errors with the INFO level
before ignoring them.
A file is known to be a Babeltrace plugin if:
* Its extension is `.so` (or `.dll` on Windows), g_module_open()
succeeds for that file, and the required
`__bt_get_begin_section_plugin_descriptors` symbol can be found.
* Its name starts with `bt_` and ends with `.py`.
Any file that does not meet the criteria above does not trigger a
loading error: the file is simply skipped.
A plugin loading error (`BT_PLUGIN_STATUS_LOADING_ERROR`) is caused by:
For a shared object (`.so` or `.dll`) plugin, one of:
* Missing `__bt_get_end_section_plugin_descriptors` symbol.
* Missing `__bt_get_begin_section_plugin_descriptor_attributes` and
`__bt_get_end_section_plugin_descriptor_attributes` symbols.
* Missing `__bt_get_begin_section_component_class_descriptors` and
`__bt_get_end_section_component_class_descriptors` symbols.
* Missing
`__bt_get_begin_section_component_class_descriptor_attributes` and
`__bt_get_end_section_component_class_descriptor_attributes`
symbols.
* Unknown plugin descriptor attribute.
* Unknown component class descriptor attribute.
* Unknown component class type in component class descriptors.
* Incompatible or missing ABI version.
* Failing plugin's user initialization function.
For a built-in plugin:
* Failing plugin's user initialization function.
For a Python plugin, one of:
* Failure to load the Python plugin module.
* Unexpected/malformed plugin info object (missing attributes, wrong
types, etc.).
With this patch, you must pass a valid file or directory path to
bt_plugin_find_all_from_file() and bt_plugin_find_all_from_dir(). When
you don't, the functions fail with `BT_PLUGIN_STATUS_ERROR`. This is not
considered a loading error (not `BT_PLUGIN_STATUS_LOADING_ERROR`), as
the user can control whether or not this error occurs by making sure
the path exists, and it does not occur while loading a plugin.
As of this patch, the CLI ignores loading errors (like before), that is,
passes `BT_FALSE` as the `fail_on_load_error` parameter. A strict mode
could be added, controlled by a command-line option.
In `native_bt_plugin.i`, wrappers are created to set the output
parameter to `NULL` if the status is not `BT_PLUGIN_STATUS_OK`. This is
similar to what was already done to wrap bt_plugin_get_version().
If you pass `fail_on_load_error=True` to bt2.find_plugins() or
bt2.find_plugin(), then this function can raise `bt2.Error` if there's
a loading error.
Tests are adapted to check the returned status code.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I88049c07163055503e9551940973390ebedcfae4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1537
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Tue, 25 Jun 2019 17:19:02 +0000 (13:19 -0400)]
lib: rename parameter of bt_self_component_filter_add_{in,out}put_port
This makes is consistent with corresponding functions for sources and
sinks. It will help for a future patch that will re-work the SWIG
bindings to have the same name everywhere (to apply the same typemap to
all of these).
Change-Id: Icdeb32711e56d4b6a619a493a8b64817f3084bd5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1534
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Wed, 19 Jun 2019 20:22:54 +0000 (16:22 -0400)]
lib: remove "accept port" concept
This patch removes the concept of a component needing to accept a port
connection before a connection is made. Since the component connections
are supposed to be transparent (a component behavior shouldn't change
based on which component is on the other side), there is no point in
letting a component refuse a connection. Refusing a port connection
based on the component class, for example, could lead to tightly coupled
components, which we want to avoid.
Change-Id: Ia2d0e09caaee069e9be22b8089ef5ccbae392bb2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1522
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 20 Jun 2019 19:54:48 +0000 (15:54 -0400)]
Fix: `ctf` plugin: do not have an `mdec` variable where not strictly needed
Issue
=====
The `metadata-info` query needs to call
ctf_metadata_decoder_packetized_file_stream_to_buf() with a custom log
level and no self component (`NULL`). Eventually, this reaches
decode_packet() which is in the `decoder.c` file and thus uses
`mdec->self_comp` to find its self component in the BT_COMP_LOG*()
macros. But in this case, `mdec` is `NULL`, so there's an invalid
memory access.
Solution
========
Instead of using BT_COMP_LOG_CUR_LVL() everywhere in this function, and
because decode_packet() and
ctf_metadata_decoder_packetized_file_stream_to_buf_with_mdec() do not
strictly need `mdec` except for logging its address at some places, move
the functions to the new `decoder-packetized-file-stream-to-buf.c` file
and make them not accept an `mdec` argument.
This new file's logging uses the local `log_level` and `self_comp`
variables, so the logging statement are not modified.
Known drawbacks
===============
None.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I55874790b2b873ff1718a774e57011300e57518d
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1526
Tested-by: jenkins <jenkins@lttng.org>
Michael Jeanson [Mon, 17 Jun 2019 20:44:24 +0000 (16:44 -0400)]
tests: Add missing copyright headers
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: If5de85403824e4a77c4a975c3354318070afb0eb
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1495
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Michael Jeanson [Thu, 13 Jun 2019 20:18:40 +0000 (16:18 -0400)]
tests: Move data files to a common directory
* Reduce errors when adding new data files, a single EXTRA_DIST
directive in tests/Makefile.am will cover all data files
* Standardise variables used to refer to the data files path and add
them to 'utils/common.sh'.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I5fd06e5280e5864593aca8e964eeda9121b8a48e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1428
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 21 Jun 2019 15:29:19 +0000 (11:29 -0400)]
bt2: add missing parameter to _UserComponentType._query
While running the Python test suite, I saw this unexpected stack trace:
test_query_not_implemented (test_component_class.UserComponentClassTestCase) ...
06-21 11:22:56.091 24065 24065 E BT2-PY bt_py3_component_class_query@native_bt_wrap.c:4442 Failed to call Python class's _query_from_native() method: py-cls-addr=0x6190001ce898
06-21 11:22:56.092 24065 24065 E BT2-PY bt2_py_loge_exception@native_bt_wrap.c:3838 Traceback (most recent call last):
File "/home/smarchi/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/component.py", line 539, in _query_from_native
results = cls._query(query_exec, obj, params, log_level)
TypeError: _query() takes 4 positional arguments but 5 were given
This is because method _UserComponentType._query is missing the
log_level argument that was added in a recent commit. The reason the
test still passes is that it expects bt2.Error to be raised (coming from
the raise NotImplementedError). The failure to call _query also ends up
raising a bt2.Error. So it succeeds to fail, but it doesn't fail the
right way, and the test fails to properly catch that failure.
Change-Id: If13bfdecc2876610fe8568a12043be60762d1596
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1530
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 21 Jun 2019 14:30:11 +0000 (10:30 -0400)]
test utils: add failfast option to our testrunner.py
When iterating on a test, I like using the -f|--failfast option of the
unittest module. This patch adds the option to pass it to our
testrunner.
Here's one way to use it (with the babeltrace build dir as the current working
directory):
tests/utils/test_python_bt2_env python3 /home/smarchi/src/babeltrace/tests/utils/python/testrunner.py /home/smarchi/src/babeltrace/tests/bindings/python/bt2/ -f
Note that this is not absolutely essential, it is also possible to call
unittest directly:
tests/utils/test_python_bt2_env python3 -m unittest discover -s /home/smarchi/src/babeltrace/tests/bindings/python/bt2/ -f
However, I prefer using the same runner as what the testsuite uses.
To facilitate the handling of optional arguments, I made the script use
argparse.
Change-Id: Ia4c082dc0952cc8649491b2410ab2d99f1477c1b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1528
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Michael Jeanson [Mon, 17 Jun 2019 16:46:29 +0000 (12:46 -0400)]
fix: move static functions inside ifdef
Move static functions inside ifdef where they are used so we don't get
unused functions warnings on MINGW.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: Ie35fcdc7b0f7bf41ed53ed06b9dfd50042510207
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1477
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Thu, 20 Jun 2019 19:50:20 +0000 (15:50 -0400)]
Fix: bt_config_convert_from_args(): set default log level at the end too
Issue
=====
There are code paths which make bt_config_convert_from_args() return a
configuration while not having set the default log level.
For example, with `-o ctf-metadata`, the function calls
bt_config_print_ctf_metadata_create() to create such a configuration,
and then goes to the `end` label).
Solution
========
Make sure it is set to the CLI's default log level value when reaching
the end of the function.
Known drawbacks
===============
None.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2ee21a754aeaea65fd6d4fbfcae5bd2f07fcba7c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1525
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Thu, 20 Jun 2019 18:23:39 +0000 (14:23 -0400)]
Rename VERBOSE log level to TRACE
Some people reported that they have a hard time guessing whether the
VERBOSE log level is more or less verbose than the DEBUG log level.
The existing logging frameworks I looked at (Apache Log4j 2, SLF4J,
`java.util.logging`, syslog, Python, Ruby, Boost.Test, ASP.NET Core, to
name a few popular ones) do not have the VERBOSE level; they almost
always have the DEBUG level, and sometimes the TRACE level.
To conform with the common practice, let's use TRACE instead of VERBOSE.
It is my wish that DEBUG vs. TRACE will speak to more developers than
DEBUG vs. VERBOSE.
This means that BT_LOGV() and its variants become BT_LOGT(). Also,
the log level environment variables and the CLI's `--log-level` parameter
accept `T` and `TRACE` instead of `V` and `VERBOSE`. In the log output,
the messages contain `T` instead of `V`:
06-20 14:31:23.356 3612 3612 T PLUGIN/CTF/BFCR
read_unsigned_bitfield@bfcr.c:483 [N/A] Read unsigned bit array:
cur=32, size=8, bo=1, val=33
`CONTRIBUTING.adoc` is updated to document the TRACE level instead of
the VERBOSE level.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I20460c4569f8b755440511c6621a68a1ef6424fc
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1524
CI-Build: Simon Marchi <simon.marchi@efficios.com>
CI-Build: Jonathan Rajotte Julien <jonathan.rajotte-julien@efficios.com>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Mon, 17 Jun 2019 16:00:21 +0000 (12:00 -0400)]
bt2: Rename _set_default_clock_snapshot_ptr callback to _set_default_clock_snapshot
I don't think it should have the _ptr suffix, as it doesn't take a SWIG
pointer object, but a uint64_t.
Change-Id: I5a6915e61cd0b482fe04a1ba62babbc3f3bc63bb
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1475
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Jonathan Rajotte [Wed, 19 Jun 2019 17:28:14 +0000 (13:28 -0400)]
Fix: Unmap before truncating
The mmap/mman compat layer for mingw uses the CreateFileMapping
and UnmapViewOfFile thus implicitly imposes an order for truncation and
ummapping [1].
For truncation calls, the underlying windows API call is SetEndOfFile.
This function requires that the file be unmapped before being called [1].
[1]
If CreateFileMapping is called to create a file mapping object for
hFile, UnmapViewOfFile must be called first to unmap all views and
call CloseHandle to close the file mapping object before you can call
SetEndOfFile.
[1] https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-setendoffile#remarks
Change-Id: Id4713ca3af612baa24e1fa4a749384eab452598a
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1519
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Michael Jeanson [Mon, 17 Jun 2019 16:54:48 +0000 (12:54 -0400)]
fix: Add missing stdint include on Windows
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I3e1369e282360401a6e0c0516828068ea15de780
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1478
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Jonathan Rajotte Julien <jonathan.rajotte-julien@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Michael Jeanson [Mon, 17 Jun 2019 16:10:34 +0000 (12:10 -0400)]
fix: test_trimmer on macOs and Solaris
The 'wc' tool on BSD based system adds leading spaces to it's output,
which breaks the quoted compare. Use bash parameter expansion to trim all
spaces from the 'num_events' variable.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I15aef8c6987e40bcb018f32c7c094eabbc3d83c3
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1476
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Fri, 14 Jun 2019 21:24:49 +0000 (17:24 -0400)]
lib: remove BT_LIB_LOG*() macro usage comment
This is explained in `CONTRIBUTING.adoc` now.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I76ed90889f4648311735b0c66389c82b2a1cf31b
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1447
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Sat, 15 Jun 2019 18:08:28 +0000 (14:08 -0400)]
Update `CONTRIBUTING.adoc`
Changes:
* Change to Asciidoctor format. This is what GitHub uses, so this guide
is correctly converted on GitHub.
* Update reference count section's terminology and function names.
* Update logging section:
* Reorganize sections, making guides explicit.
* Header paths.
* More details about the available log levels.
* Library-specific logging statement macros (more or less copied from
`src/lib/logging.h`).
* Component-specific logging statement macros.
* Have clear guides on how to instrument generic, library, and
component class C source and header file
* More details about which log level to choose.
* More details about which logging tag to choose.
Removing the `CONTRIBUTING.html` global Makefile target as we cannot
use Asciidoc to build `CONTRIBUTING.adoc` anymore.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I98effa1fb087274c453014d95115d471b5b115ad
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1446
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Wed, 19 Jun 2019 07:11:36 +0000 (03:11 -0400)]
lib: add comment about why `bt_lib_log_level` is exported
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ic3dd3ff9cb6f39ac369a55c06ef9a752d60d7fc7
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1512
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
This page took 0.05497 seconds and 4 git commands to generate.