Fix: metadata stream is not marked as quiescent after packet commit
authorJérémie Galarneau <jeremie.galarneau@efficios.com>
Mon, 10 Jun 2019 17:31:31 +0000 (13:31 -0400)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Thu, 25 Jul 2019 19:51:46 +0000 (15:51 -0400)
commit0d88e04674ead21c741c6f4ed7fadf666c5e7bce
treeee3c6f9a7641b149d7f2cc88599c884d29b5dd22
parentd295668767ac8234e83984e1812d342d03293d88
Fix: metadata stream is not marked as quiescent after packet commit

When a metadata stream's wait fd is hung-up or enters an error state,
it is checked for quiescence in lttng_ustconsumer_on_stream_hangup().

If the stream is not quiescent, the current packet is closed through
the flush_buffer operation.

Currently, all commits to metadata streams are done on a packet
basis. The various code paths using the commit_one_metadata_packet
helper all perform a flush directly after the commit. Performing this
flush leaves the stream in a "quiescent" state, but does not mark it
as such.

This results in an extraneous flush being performed in the err/hup
handler, which leaves an empty packet to be consumed.  This packet is
then consumed during the execution of the err/hup handler.

This bug results in an empty packet being appended to metadata
streams. This packet is typically ignored by readers, but the fact
that it is written at the time of the destruction of a session
violates the immutability guarantee of the session stop
command. Moreover, following the introduction of trace chunks, this
results in the stream attempting to serialize the empty buffer to its
output file _after_ its trace chunk has been closed, causing an
assertion to hit.

Hence, this fix performs the buffer flush and sets the stream as
quiescent directly in commit_one_metadata_packet().

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
src/common/ust-consumer/ust-consumer.c
This page took 0.025888 seconds and 4 git commands to generate.