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, 5 Sep 2019 20:39:13 +0000 (16:39 -0400)
commitd367ba5493d6bcd2163989e051f1b0e8c7e19288
treeeb95572232402717d3befa2f98b8af77b6dd49c3
parente5148e25a481691b3278cd85a6ff25c1e25e4d2e
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.025585 seconds and 4 git commands to generate.