Fix: metadata channel leak when using the snapshot tracing mode
authorJérémie Galarneau <jeremie.galarneau@efficios.com>
Thu, 8 Feb 2018 23:25:55 +0000 (18:25 -0500)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Fri, 9 Feb 2018 21:40:08 +0000 (16:40 -0500)
commitf65a74beeeb07878df549f75a65209a765892b25
tree76a6a11b044215b4731dedaac2778d455825e9fb
parent9e21835385dae360737a08a6119cf870b68f44f6
Fix: metadata channel leak when using the snapshot tracing mode

While running stress tests involving the snapshot mode, it
becomes apparent that the lttng-consumerd leaks a number of file
descriptors.

To isolate the problem, the test was narrowed down to

* Create a session in snapshot mode
* Enable a userspace channel
* Enable all userspace events
* Start tracing
* Run a traced application
* Stop tracing
* Destroy session

This has shown that 5 file descriptors were leaked on each
iteration of the above.

As the comments in this change indicate, the ownership and
lifetime of metadata channels varies depending on the tracing
mode being used.

In non-snapshot tracing modes, metadata channels are owned by
their respective streams. On destruction of a metadata stream,
consumer_del_channel() is invoked since the stream releases its
ownership of the metadata channel.

However, this relationship between metadata streams and channels
does not exist in snapshot mode; streams are created and
destroyed on every snapshot record. Hence, the
LTTNG_CONSUMER_CLOSE_METADATA command must immediately clean the
metadata channel.

The channel's "monitor" flag is used to determine whether or not
the metadata channel is in "snapshot" mode or not.

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