-
d4014ae...
by
Jérémie Galarneau <email address hidden>
on 2019-06-25
-
Update version to v1.5.7
Signed-off-by: Jérémie Galarneau <email address hidden>
Change-Id: I4d3c374e762888679474b3330bf959b87d3910d2
-
51950aa...
by
Mathieu Desnoyers
on 2019-05-17
-
Cleanup: bitfields: streamline use of underscores
Do not prefix macro arguments with underscores. Use one leading
underscore as prefix for local variables defined within macros.
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: Ie1c2f7f59f605ac62d483aba67b3f70cef27bf21
Signed-off-by: Jérémie Galarneau <email address hidden>
-
c15e060...
by
Mathieu Desnoyers
on 2019-05-17
-
Fix: bitfield: shift undefined/implementation defined behaviors
bitfield.h uses the left shift operator with a left operand which
may be negative. The C99 standard states that shifting a negative
value is undefined.
When building with -Wshift-negative-value, we get this gcc warning:
In file included from /home/smarchi/src/babeltrace/include/babeltrace/ctfser-internal.h:44:0,
from /home/smarchi/src/babeltrace/ctfser/ctfser.c:42:
/home/smarchi/src/babeltrace/include/babeltrace/ctfser-internal.h: In function ‘bt_ctfser_write_unsigned_int’:
/home/smarchi/src/babeltrace/include/babeltrace/bitfield-internal.h:116:24: error: left shift of negative value [-Werror=shift-negative-value]
mask = ~((~(type) 0) << (__start % ts)); \
^
/home/smarchi/src/babeltrace/include/babeltrace/bitfield-internal.h:222:2: note: in expansion of macro ‘_bt_bitfield_write_le’
_bt_bitfield_write_le(ptr, type, _start, _length, _v)
^~~~~~~~~~~~~~~~~~~~~
/home/smarchi/src/babeltrace/include/babeltrace/ctfser-internal.h:418:3: note: in expansion of macro ‘bt_bitfield_write_le’
bt_bitfield_write_le(mmap_align_addr(ctfser->base_mma) +
^~~~~~~~~~~~~~~~~~~~
This boils down to the fact that the expression ~((uint8_t)0) has type
"signed int", which is used as an operand of the left shift. This is due
to the integer promotion rules of C99 (6.3.3.1):
If an int can represent all values of the original type, the value is
converted to an int; otherwise, it is converted to an unsigned int.
These are called the integer promotions. All other types are unchanged
by the integer promotions.
We also need to cast the result explicitly into the left hand
side type to deal with:
warning: large integer implicitly truncated to unsigned type [-Woverflow]
The C99 standard states that a right shift has implementation-defined
behavior when shifting a signed negative value. Add a preprocessor check
that the compiler provides the expected behavior, else provide an
alternative implementation which guarantees the intended behavior.
A preprocessor check is also added to ensure that the compiler
representation for signed values is two's complement, which is expected
by this header.
Document that this header strictly respects the C99 standard, with
the exception of its use of __typeof__.
Adapt use of _bt_piecewise_lshift in plugins/text/pretty/print.c
to the new API.
Signed-off-by: Mathieu Desnoyers <email address hidden>
Acked-by: Simon Marchi <email address hidden>
Signed-off-by: Jérémie Galarneau <email address hidden>
Change-Id: Icf02c4a6d2b7fb955d36f2843eaf62b8ceef5679
-
e7f1ad3...
by
Jérémie Galarneau <email address hidden>
on 2019-04-04
-
Fix: array and sequence field's 'elems' members can be left NULL
Issue
---
The behaviour of a number of "rw" functions associated with array and
sequence field types differ when their element's declaration meets the
following criteria:
- is an integer,
- is byte-aligned,
- is byte-sized,
- is UTF-8 or ASCII encoded.
Those criteria are used to determine if the elements of either arrays
or sequences should be interpreted as characters.
1) The implementation of sequence and array definitions creation
functions do not initialize their 'elems' member (a g_ptr_array),
instead initializing a 'string' member (a g_string).
2) The 'ctf' format plug-in does not initialize the 'elems' array with
the decoded integer definitions, instead only initializing the
'string' member with the field's contents.
3) The 'ctf-text' format plug-in uses the internal headers to
access the 'string' member of those definitions directly.
The 'string' member of both sequence and array definitions is meant as
a helper to allow the access to their contents in textual form.
However, while an array's content is made available under that form
through the public bt_ctf_get_char_array() function, there is no
equivalent accessor for the sequence type, as reported by a number of
users [1][2]. The 'ctf-text' format implementation works around this
limitation by making use of the internal headers to access the string
member directly.
Moreover, bypassing the creation and initialization of the 'elems'
member of both array and sequence definitions results in a crash when
bt_ctf_get_field_list() is used with these types when they contain
character elements, as reported on the mailing list [1].
Solution
---
This fix eliminates the bypass used by the definition creation
functions and 'ctf' format plug-in, ensuring that both the 'string'
and 'elems' members are initialized even if the elements fit the
"character" criteria.
This fixes the crash on a unchecked NULL pointer in
bt_ctf_get_field_list() reported in [1] when trying to access the
sequence's contents.
The checks for the various criteria that make an integer a
character have been moved to an internal function, bt_int_is_char()
since their (incorrect) duplication obscured the underlying problem.
For instance, a sequence's 'string' member is allocated if the
elements are ASCII or UTF-8 encoded integers, but only used when
the elements are byte-sized and byte-aligned (as opposed to the
intended behaviour in types/array.c).
With this fix applied, sequence elements can be accessed normally
through the existing bt_ctf_get_field_list() or bt_ctf_get_index()
functions.
Example:
```
/*
* Print a sequence's content if it is text.
* Error handling omitted.
*/
void print_sequence(const struct bt_ctf_event *event,
const struct bt_definition *sequence_definition)
{
int signedness, integer_len;
unsigned int i, element_count;
const struct bt_definition * const *elements;
const struct bt_definition *element;
const struct bt_declaration *element_declaration;
enum ctf_string_encoding encoding;
bt_ctf_get_field_list(event, sequence_definition, &elements,
&element_count);
if (element_count == 0) {
return;
}
/* Is this a text sequence? */
element = elements[0];
element_declaration = bt_ctf_get_decl_from_def(element);
if (bt_ctf_field_type(element_declaration) != CTF_TYPE_INTEGER) {
/* Not a text sequence. */
return;
}
signedness = bt_ctf_get_int_signedness(element_declaration);
encoding = bt_ctf_get_encoding(element_declaration);
integer_len = bt_ctf_get_int_len(element_declaration);
if (integer_len != 8 ||
(encoding != CTF_STRING_UTF8 && encoding != CTF_STRING_ASCII)) {
/* Not a text sequence. */
return;
}
putchar('"');
for (i = 0; i < element_count; i++) {
int val = signedness ?
bt_ctf_get_int64(elements[i]) :
bt_ctf_get_uint64(elements[i]);
putchar(val);
}
putchar('"');
}
```
Notes
---
Since it is not possible for a user of the public API to determine the
alignment of a field in the ctf trace, it is not possible to check for
the criteria that make an array a "character array".
An array's element declaration could indicate that it is a byte-sized
and UTF8/ASCII encoded integer. Yet, the 'string' member could be left
NULL if the element's alignment is not '8'.
Hence, while it is possible to use the bt_ctf_get_char_array()
function on array definitions that look like "character arrays", users
should be careful in doing so.
bt_ctf_get_char_array() returning NULL should not be assumed to
indicate that an array is empty. Under such circumstances, reader code
should fall-back to using bt_ctf_get_field_list() to access the
array's contents, as shown in the example above.
[1] https://lists.lttng.org/pipermail/lttng-dev/2019-April/028704.html
[2] https://github.com/efficios/babeltrace/pull/98
Reported-by: romendmsft <email address hidden>
Reported-by: Milian Wolff <email address hidden>
Signed-off-by: Jérémie Galarneau <email address hidden>
-
9d4e072...
by
Jérémie Galarneau <email address hidden>
on 2018-10-30
-
Fix: invalid alignment of enumeration fields
Issue
---
According to the CTF specification, the alignment of an enumeration is
that of its container integer field declaration. However, an
enumeration field's alignment is always initialized to 1.
This causes babeltrace to fail to read traces produced by lttng-ust
following a fix that causes it to generate extended event headers. The
problem is observed on ARM platforms since lttng-ust will produce a
layout that does not result in unaligned memory accesses.
Solution
---
The alignment of the enumeration declaration's container is sampled
when the enumeration declaration is created.
Signed-off-by: Jérémie Galarneau <email address hidden>
-
4f10a4a...
by
Jérémie Galarneau <email address hidden>
on 2018-07-03
-
Update version to v1.5.6
Signed-off-by: Jérémie Galarneau <email address hidden>
-
9ee3384...
by
Jérémie Galarneau <email address hidden>
on 2018-07-03
-
Fix: remove left-over debug logging statement
Signed-off-by: Jérémie Galarneau <email address hidden>
-
c8a6831...
by
Jonathan Rajotte
on 2018-07-03
-
Use trace->trace_id in check to remove trace from bt_ctx
Commit b9e6498df8b3e7c2ad312dccddf9f1a5e181648e removes the existence
guarantee of the trace_id hash table key by moving the trace->in_use
assignation before the assignation of trace_id and insertion into the
hash table.
Use the trade_id field value to validate if it should be removed from
the hash table. A NULL trace_id field indicates that no insertion was
performed.
This is mostly a workaround to a problem found in, at least, glib 2.28
where g_hash_table_lookup_node() aborts on a SIGFPE signal due to
modulo by zero. The exact cause for this is unknown for now, but a
similar problem was reported against Nautilus [1].
There is little reason for "mod" to be 0 at that point, as explained
in the bug report.
Currently unable to reproduce.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1074401
Signed-off-by: Jonathan Rajotte <email address hidden>
Signed-off-by: Jérémie Galarneau <email address hidden>
-
5223ed8...
by
Jérémie Galarneau <email address hidden>
on 2018-06-08
-
Fix: missing initializer braces warning
Signed-off-by: Jérémie Galarneau <email address hidden>
-
340a47b...
by
Francis Deslauriers <email address hidden>
on 2018-05-04
-
Fix: zero out URL parsing array before use and ensure proper error reporting
The remain[2] array is being used uninitialized when such URI is used:
`net://localhost:1234`.
The following line (142) will return 1:
`ret = sscanf(remain[0], ":%d%s", &ctx->port, remain[1]);`
because `sscanf` won't match on the string (%s) delimiter.
This will leave `remain[2]` uninitialized.
This potentially uninitialized array is being used further down the function.
As a fix, we zero out the array at initialization time to prevent the
`strlen(remain[2])` call from using uninitialized memory.
Signed-off-by: Francis Deslauriers <email address hidden>
Signed-off-by: Jérémie Galarneau <email address hidden>
