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, 26 Sep 2019 19:37:53 +0000 (15:37 -0400)
commit9dfbcccfb87c30a74c6059b24bfc053bdcddee54
tree49a4b565f4a11b7c40e03fdc84144e7e474380bf
parentaf52ad2150c2d99e462c57264ce796ae1d70d499
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.025113 seconds and 4 git commands to generate.