trimmer: close when end is reached

When an event has a timestamp past the specified end timestamp, the
iterator now returns it is end which closes the graph. We also check if
the timestamp begin of a packet is after the end timestamp.

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

trimmer fix: notification handling

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

debug_info: fix graph connection

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fix copytrace: set the byte order

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

copytrace: option to skip the copy of packet/content size

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fix: optional fields

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/graph/notification/event.c: fix clock class leak

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/graph/port.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Remove component's initialization state flag

This "initializing" flag is now useless. It was used to make sure that
only the implementation side of a component could set the component's
private user data. This is now enforced by typing (component vs. private
component), and it is always okay to set a private component's user
data.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/graph/component.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

bt_ctf_stream_map_component_to_port(): log before and after

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Remove bt_component_set_name()

This is not used anywhere, and there's not even a public declaration for
it. Plus a component object has no frozen property, and for obvious
reasons we can't change the name of a component once it's part of a
graph. All the properties of a component must be set at creation time.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/graph/graph.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Remove bt_graph_add_component_as_sibling()

This is not used anywhere, and it's one more thing to test. It remains
in the archives in case we need it in the future. This was created in
the days when it was expected that components would duplicate themselves
to share resources instead of dynamically adding ports like today.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

bt_ctf_trace_destroy(): logging: difference between destroying and putting

In some cases we know for sure that we're destroying the objects, not
just putting them.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

bt_ctf_stream_class_destroy(): log what is being destroyed/put

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/event-class.c: minor logging message edit

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/validation.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

ref.c: warn when the ref count goes from 0 to 18446744073709551615

This unlikely conditin indicates a double bt_put(), or something that
went really wrong, and should be reported to the user as a warning.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

ref.c: do not change ref count when release function is not set

This is the case of the null value singleton, bt_value_null, on which
you can call bt_get() and bt_put() and they should have no effect.
Before this patch, we can see log messages of the ref count going from 0
to 18446744073709551615 and other weird, huge values.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/resolve.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

field-path.c: add internal function to stringify a field path

This is to be used by logging statements.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/trace.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

ctf.fs source: make traces static when all streams are created

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

plugin-so.c: use BABELTRACE_NO_DLCLOSE env. var. to avoid dlclose()

See new comment in plugin-so.c.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

ctf.fs source: add trace file rotation (stream instance ID) support

ctf.fs source is changed as such:

* A CTF FS trace owns zero or more stream file groups.

* A stream file group owns a unique CTF IR stream object and one or more
  stream file infos.

* A stream file info contains a path and a beginning timestamp (the
  beginning timestamp of the stream file's first packet).

* Stream file infos are ordered by time in a stream file group.

* One output port is created for each stream file group. It is also
  associated to this stream file group through private port's user data.

  The name of the port is always the stream file group's first stream
  file info's path, which is always the path of stream file containing
  the oldest packet. This can be useful to isolate a group of stream
  files by name and possibly CPU ID, e.g. (CPU 1 of LTTng channel
  `my-channel`):

      --connect='ctf.*my-channel_1_*:mux'

  or all CPUs of LTTng channel `hello-chan`:

      --connect='ctf.*hello-chan_*:mux'

* The user data of a notification iterator contains its upstream port's
  stream file group and a stream file info index.

* For a given notification iterator, one data stream file object (owner
  of a binary notification iterator and the one which does the stream
  file memory mapping) is always active. When it returns a
  BT_NOTIFICATION_ITERATOR_STATUS_END status, the data stream file is
  destroyed and the next stream file info is used to create a new data
  stream file, from which the real next notification is obtained. If
  there's no more stream file info in the stream file group, then
  BT_NOTIFICATION_ITERATOR_STATUS_END is returned.

This patch effectively makes a ctf.fs source component create one unique
stream, and thus one port, for each stream instance of each trace,
therefore supporting trace file rotation. Only one stream file is
opened and memory mapped at any time for a given stream instance.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

ctf plugin: add bt_ctf_notif_iter_get_packet_header_context_fields()

The new bt_ctf_notif_iter_get_packet_header_context_fields() function
returns the packet header and context fields using the usual medium
operation mechanism without ever creating packet of event objects,
therefore not requiring a stream object to exist.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

ir: add stream ID API

The new bt_ctf_stream_create_with_id() function creates a stream object,
just like bt_ctf_stream_create(), but with a numeric ID. You cannot
call this function to create a CTF writer stream because CTF writer
streams initialize their own unique ID.

Use bt_ctf_stream_get_id() to get a stream's ID.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

cli: --force-correlate -> utils.muxer's `ignore-absolute` parameter

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: do not require lttng-utils.debug-info with --disable-debug-info

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: ctf.fs source: append all ctf_fs_trace objects to component's list

This avoids obvious potential leaks.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

ctf.fs source: recurse to find multiples CTF traces

One port per CTF data stream amongst all the traces that are found
from the user's starting path is created.

The traces are named so as to be able to replicate the original tree
by stripping their common prefix within slash boundaries.

For example: user passes `hello` as the starting path, the component
finds the following traces:

    hello/world/kilo
    hello/yes
    hello/ispep/zero/mini

These traces would be named:

    world/kilo
    yes
    ispep/zero/mini

Another example: user passes `hello` as the starting path, the
component finds the following trace:

    hello/world/kilo

In this case, the trace is named `kilo`.

I used realpath() to normalize the paths and make sure that there aren't
`.` or `..` in the trace's name. Opening a trace located directly in `/`
is not supported.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix warnings emitted by `gcc -Wall`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Library: log version (INFO) on construction

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

babeltrace(1): reset console after graph stops running

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

logging-internal.h: use __attribute__((format)) to check parameters

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Logging: fix wrong parameters, superfluous commas, etc.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/event.c: replace some BT_LOGE() with BT_LOGW()

Field serialization can fail because of a user error, for example trying
to serialize a field which is not set.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

CTF writer: stream: handle automatic fields more securely

The stream.c code for automatically writing the values of selected
fields in the packet context, packet header, and event header fields is
not super secure, in that the user could make the stream object write an
invalid CTF data stream file.

The code is updated to follow those rules:

* Packet header field:
  * `magic` field: always force to 0xc1fc1fc1. Override any current
    value.
  * `uuid` field: always force to trace's UUID. Override any current
    value.
  * `stream_id`: always force to stream's class's ID. Override any
    current value.
* Packet context field:
  * `packet_size`: always force to the size of the packet being flushed.
    Override any current value.
  * `packet_size`: always force to the current packet's offset. Override
    any current value.
  * `timestamp_begin`: if the field's type is mapped to the stream's
    class's clock class, force to the timestamp of the stream's first
    recorded event (if any, and if this timestamp is itself mapped to
    the same clock class), overriding the user's value.
  * `timestamp_end`: if the field's type is mapped to the stream's
    class's clock class, force to the timestamp of the stream's last
    recorded event (if any, and if this timestamp is itself mapped to
    the same clock class), overriding the user's value.
  * `events_discarded`: always force to the stream's current discarded
    events count (now a dedicated member of the stream object to keep
    this value safe). Override any current value.
* Event header field:
  * `timestamp`: if the field's type is an integer field type which is
    mapped to the stream's class's clock class, force to the current
    value of the stream's class's clock, overriding the user's value.
  * `id`: if the field's type is an integer field type, force to the
    event's class's ID, overriding the user's value.
* If the stream's packet context does not exist or does not contain
  a `packet_size` field, the user can only flush the stream one time.
* If the stream's packet context does not exist or does not contain a
  `content_size` field, the content size (current offset) of the packet
  to flush must be equal to its packet size.

Those rules are more strict than before, but they ensure that the
written stream is valid. Writing an invalid CTF stream, or CTF trace at
all, is not a CTF writer use case. This is in line with the project's
first precept: don't trust the user.

I added assertions which check that the packet size is always a multiple
of 8: this is suggested by CTF 1, and required by (eventual) CTF 2. This
is always the case here because the packet's initial size is 8 pages and
then it's incremented by this value each time. If it is a requirement
that the user should be able to control the packet size, then we should
add a function to set the expected packet size before flushing the
stream, not rely on the `packet_size` field's value.

There are still a few cases which remain to be checked. For example, if
the stream class's event header field type's `id` field does not exist,
and there's more than one event class in the stream's class, we write
the event anyway without any warning: this is because LTTng is known to
have a complex system of `id` and `timestamp` fields with extended
structures depending on the ID value, and the ctf.fs sink component
class uses CTF writer as is. That said, in the most common scenarios,
`id` is an integer field type.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Validate CTF semantics in selected CTF IR functions

Before this patch, the semantics suggested by the CTF specification are
not validated in CTF IR itself. For example, the library does not
enforce that, if there's more than one stream class contained in a given
trace, its packet header field type's `stream_id` field must exist
(which also means that the packet header field type must be set).

When you add a stream class to a trace created by a CTF writer object
(implicit when you call bt_ctf_writer_create_stream(), for example), we
proceed to automatically map selected field types to the stream class's
clock if it's set. Those fields are:

* Packet context field type: `timestamp_begin`
* Packet context field type: `timestamp_end`
* Event header field type: `timestamp`

If those fields are not mapped to a clock class, and if there's no
current stream class's clock, then the whole
bt_ctf_trace_add_stream_class() function fails.

Those mappings are needed to make a valid CTF trace. The field types
cannot be mapped at stream class creation time because the user can
override the packet context and event header field types and still have
those fields without a mapping. To make this use case more easy in CTF
writer context, the mapping is always done automatically in
bt_ctf_trace_add_stream_class().

This has the side effect that this sequence of operations is not valid
anymore:

1. Create a trace.
2. Create a default stream class with bt_ctf_trace_add_stream_class().
3. Add the default stream class (2) to the created trace (1).

Because bt_ctf_trace_add_stream_class() creates an initial packet
context field type which contains the `timestamp_begin` and
`timestamp_end` fields, and because those fields are only valid at
bt_ctf_trace_add_stream_class() call time when they are mapped to a
clock class, and because we're not in CTF writer context, then they are
not automatically mapped. This is why, in non CTF writer mode (graph
mode), the user should prefer bt_ctf_stream_class_create_empty(), or
manually get the `timestamp_begin` and `timestamp_end` field types and
map them to a clock class which is also part of the trace in which to
add the stream class.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Event notification: make sure contained event has a trace

Because we need to keep support for legacy CTF writer behaviours, we can
still create a "floating" event without its stream class attached to a
trace. Disallow the creation of an event notification with such an event
to provide the guarantee to filter and sink components that you can
always find the trace of an event notification's event.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/stream.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

fields.c: get non-existing field: log level WARN -> VERBOSE

It is possible that a user needs to check if a structure field's field,
for example, is set (exists). If it does not, the given function returns
NULL, but this is not an error: the function is used to check here, not
to create the field.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

bt_ctf_event_serialize(): do not log whole function (done in stream.c)

We already log the current event being serialized in
bt_ctf_stream_flush(): do not log twice.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: lttng-live enum mismatch

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-types.c: use `int`, not `int64_t` for return value

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: lib/ctf-ir/event-class.c: fix warnings on `ret` condition

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: g_quark_try_string() is usually not a WARN trigger

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: set no field in event/packet without warnings or failing

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lttng-live: handle EINTR and graph cancelation

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: invoke bt_ctf_trace_set_is_static only when trace is destroyed

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/utils.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/fields.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/values.c: add more verbose/debug logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/packet.c: add more debug logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/event-class.c: add more verbose/debug logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/attributes.c: add assert()

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Update logging guide: more about the WARN level

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-types.c: logging: log more details

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/event.c: logging: fix log levels and more verbose/debug logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-types.c: logging: log struct/var FT field destruction

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-types.c: logging: log only specific functions

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-types.c: logging: log more details when freezing

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lttng-live: change loglevel env var to BABELTRACE_PLUGIN_CTF_LTTNG_LIVE_LOG_LEVEL

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lttng-live: ensure that port connections go to the same component

Also has tiny cleanups.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: don't call iterator finalize more than once

A finalize may have side-effects that trigger port removal, thus calling
finalize again. Ensure it is not called more than once.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix: muxer: handle CANCELED status

Since commit bbd6694a2 "Collect useless graph's connections", the
lttng-live component may return a CANCELED state to the muxer. The muxer
should deal with this state as an "END" state.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Update logging guide

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-types.c: add verbose logging (modifying functions)

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

LTTng live: use common url parser

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Implement cmd_print_lttng_live_sessions

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/values.c: use assert() instead of checking error

In this case we know that it should not fail.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/stream-class.c: logging: fix typo

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Logging: use WARN level where appropriate

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-types.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

cli/babeltrace.c: logging: add details in graph listeners

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/field-path.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/values.c: logging: log original and copy addresses

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ref.c: logging: show current count and new count in messages

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/stream-class.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/event.c: logging: remove some context given by other statement

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/values.c: logging: log array size when out of bound

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/event-class.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/event.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Add internal bt_ctf_field_type_id_string()/byte_order_string()

This is to be used by logging.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/values.c: logging: log value's type name

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/clock-class.c: improve logging with clock class's name

Clock class log statements should be easier to follow with a clock
class's name field.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Include <babeltrace/lib-logging-internal.h> before anything else

This makes sure that headers which would need this to be included see
what it defines.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

cli/babeltrace.c: improve main loop's logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

cli/babeltrace.c: handle usleep()'s error

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

lib/ctf-ir/packet.c: add logging

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

cli/babeltrace.c: do not call load_all_plugins() in commands

main() already calls load_all_plugins() when the configuration asks to.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

logging-internal.h: fix include name in comments

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

include/babeltrace/object-internal.h: add logging

Because the static inline functions are instrumented in the header
itself, it cannot have its own tag. So this header MUST be included
AFTER including <babeltrace/logging-internal.h>, or anything that
includes this (like <babeltrace/lib-logging-internal.h>).

ctf.lttng-live is modified to respect this, as well as various
instrumented library source files.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Collect useless graph's connections

Before this patch, the connections accumulate in the graph's array of
connections and are never destroyed until the graph is destroyed.
However, because it is possible to disconnect the ports of a connection,
it is possible that a graph contains connections that are useless. This
can cause a "leak" of connections, which would be especially experienced
with a graph that contains a source which dynamically adds and removes
many ports that are connected during its lifetime.

The conditions for a connection to be considered useless are:

1. Its reference count is 0. This means only its parent, the graph,
   controls its existence.
2. Its ports are disconnected.
3. All its created notification iterators are finalized.

When all the conditions above are satisfied, it is safe to remove the
connection from its parent graph.

Conditions 2 and 3 can be checked in:

* bt_connection_disconnect_ports(): The connection is dead, detached
  from its ports, and vice versa, thus satisfying condition 2.
* bt_connection_remove_iterator(): The number of notification iterators
  changes; could drop to 0, thus satisfying condition 3.

To accomodate condition 1, a new concept is added to the base object: it
is possible to set a "parent is owner" listener which is called when the
parent becomes the owner of the object (that is, when the object's
reference count drops to 0 and it has a parent). Connection objects use
this callback to possibly remove itself from its parent when all three
conditions above are satisfied.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Implement logging in lttng-live component

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

cli/babeltrace.c: add logging when the command completes

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

babeltrace(1): handle SIGINT to cancel the graph gracefully

It goes like this:

1. Ctrl+C
2. SIGINT
3. sigint_handler()
4. Cancel the application's graph.
5. bt_graph_run() eventually returns BT_GRAPH_STATUS_CANCELED or
   BT_GRAPH_STATUS_AGAIN.
6. When we get those statuses, we check if the graph is canceled and
   quit the loop if so.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

Fix possible leaks in graph's current design

There was a possible leak when, for example:

* The user has a reference to the graph.
* The graph holds its child sink component.
* The sink component has a reference to a notification iterator.
* The notification iterator has a reference to the source component.
* The source component has a reference to its parent, the graph, because
  its reference count is 1 (owned by the notification iterator).

This forms a cycle: sink component owns the notification iterator, which
owns the source component, which owns the graph, which holds the sink
component.

To break this cycle and still guarantee that the lifetime of a
notification iterator's upstream component is equal to or longer than
this iterator's lifetime, we split the notification iterator's
destruction and finalization (user's finalization method) phases. In
other words, a notification iterator can be finalized without being
destroyed. However it is guaranteed that it is always finalized once
destroyed.

A connection keeps a set of created notification iterators (weak
references). There are two possible paths to finalize a notification
iterator:

1. The graph still exists and is not being destroyed, and the final
   reference to the notification iterator is put: the notification
   is destroyed, and since it has not been finalized yet, it's
   finalized during that phase.

2. The graph is being destroyed, and an owner (or more) still owns a
   reference to the notification iterator. The graph's destructor first
   destroys the graph's connections. Each connection finalizes each
   notification iterator in its list, but does not destroy them.
   The notification iterators are marked as finalized. Eventually the
   graph destroys its components, some of which could put the last
   reference to a notification iterator: the notification iterator is
   destroyed, but not finalized twice.

When a notification iterator is marked as finalized, calling its "next"
method returns the new BT_NOTIFICATION_ITERATOR_STATUS_CANCELED status
when its queue is empty (instead of BT_NOTIFICATION_ITERATOR_STATUS_END).

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

BT_GRAPH_STATUS_CANCELED is not an error, thus use a positive value

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>