Fix: build failure using disable-lttng-ust configure option
A stub for ust_app_get_size_one_more_packet_per_stream() is missing
which causes the build to fail when using the --disable-lttng-ust
configuration option.
There are a few issues with snapshot size: when taking a snapshot
without specifying any "max size" (should be unlimited), only a single
packet from each stream is saved. We expect all stream available content
to be saved. There is a similar issue when a max size is specified.
Also, trying to make all streams save as much data has unexpected
corner-cases: for instance, if we have this configuration:
- kernel channels: 2 subbuffers of 1MB x 8 CPUs
- per-PID UST channels: 16 subbuffers of 4kB x 8 CPUs x 100 apps
would require the user to have a very large max size, since it would try
to fit (8 + (100 * 8)) * 1MB = 808MB of sub-buffers, else it would fail.
This issue here is using the largest subbuffer size as the criterion
applied to all channels.
We fix those issues by simplifying the algorithm used to calculate how
much data to grab. Rather than calculating the size to grab from each
stream, we calculate a number of packets to grab. It fails if we cannot
grab at least one packet from each stream in the session. Then checks if
it can grab 2 packets from each stream, and so on, until there is no
more space available (based on max size). This is not a perfect
solution, but has the merit of being simple to understand, and has no
(or few) unexpected corner-cases.
Commit c4b88406 "Fix: ust-app: per-PID app unregister vs tracing stop
races" introduces a regression for per-UID flush. It can be triggered by
the test_high_throughput_limits (root regression) test. For per-UID
tracing, we need to use the registry channel ID, not the per-application
channel ID, when asking the consumer daemon to flush.
When doing this fix, we notice that the locking rules of push_metadata()
are weird. A per-ust app session lock is protecting registry data, which
makes it impossible to call push_metadata from a ust session level (for
the entire session) in the case of per-UID tracing. Moreover, it's
unclear how holding a per-application lock can protect a registry shared
across applications in per-UID tracing. Therefore, we move all accesses
to the registry metadata_key and metadata_closed fields into the
registry lock critical section. We now only rely on RCU to ensure
existance of registry across push_metadata(), rather than relying on the
per-application session lock.
It also takes care of a documentation vs code mismatch: push_metadata()
documents that "The session lock MUST be acquired here before calling
this.", but in reality, it's the application session lock which is held
across those calls. Removing this requirement, and relying on RCU
instead, fixes this mismatch.
Use the bash shell "wait" to wait for all background tasks rather than
the racy "pidof". Indeed, it's possible that applications have been
forked, but not executed yet, when pidof is done, which would therefore
miss applications. Using "wait" from the shell solves this.
If we want to be really strict, we should have sessiond, consumerd, and
relayd export a file containing their own PID, and wait for this instead
of using pidof. But this will be for another fix.
Exit threads as soon as number of FD is 0, on every loop (no need for
goto restart special case). Number of FD being 0 is a sufficient
condition for exiting the thread: it means the quit pipe has been
removed from the poll set.
poll:
- fix two nb_fd off by one in "add",
- simplify array size calculation,
- add error checking,
- compress the content of array before resizing it on "del"
(out-of-bound memory access issue),
- set wait.nb_fd = 0 when no FD are present in array on wait,
- remove need_realloc flag: this can be checked internally by comparing
current->alloc_size and wait->alloc_size. Minimize the number of
duplicated state.
epoll:
- add error checking,
- simplify array size calculation (make it similar to poll),
- Set default size when poll_max_size is 0 within
compat_epoll_set_max_size(), which allow better error checking
elsewhere in epoll compat code.
Fix: ust-app: per-PID app unregister vs tracing stop races
There are various races with UST application unregister performed
concurrently with tracing stop operation when tracing with per-pid
buffers. This randomly affects availability of data shortly after the
data pending check returns that no more data is available.
ust_app_stop_trace_all() iterates on all applications in the ust_app_ht
hash table to issue a flush on all buffers. This is needed to ensure
that the sub-buffers being written to are made available to the
consumer, for both data consumption, and for the data pending check.
Failure to execute the sub-buffer flush makes following data pending
check return that there is no data in the buffers too early, thus
resulting in an incomplete trace.
It is therefore important that an application flushes all its buffers
before it is removed from the ust_app_ht.
This is where ust_app_unregister() needs to be fixed. Note that
ust_app_unregister() executes concurrently with
ust_app_stop_trace_all(), only taking the per-session lock. The order of
flush vs hash table removal therefore matters:
We need to push the metadata before removing application from
ust_app_ht. We also need to issue a flush for all application buffers
before removing the application from ust_app_ht.
Once this is fixed, there is yet another race, this time in
ust_app_flush_trace() (now renamed ust_app_flush_session()). It is
caused by the use of ustctl_sock_flush_buffer() which asks the
application to perform the buffer flush. Unfortunately, if the
application vanishes (not reachable anymore), but its unregistration has
not yet been processed by sessiond, then ust_app_stop_trace_all() will
fail to flush the application buffers, because
ustctl_sock_flush_buffer() will fail.
This final issue is fixed by asking the consumer daemon to flush the
associated channel rather than relying on the application.
There are cases where a stream can be completely empty (no packet to
write) with UST: for instance, if a traced application is either
preempted for a long time, terminated, or stopped, between reserve and
commit. This will make the consumer consider that this stream has no
data ready. If this situation occurs in the first sub-buffer of a
stream, this stream will have no data at all (0 bytes).
Therefore, we need to let the data pending check consider that no data
is pending in this situation, otherwise it can make the data pending
check always return that there is data pending.
The "break" statement on error skips the rest of the functions, thus
leaving test applications running after the end of the test, which is a
side-effect on the following tests.
Fix: don't destroy the sockets if the snapshot was successful
Missing a goto to skip the error condition that was destroying the
relayd sockets even if a snapshot was successful. We want to keep them
open to reuse them for the next snapshots.
Philippe Proulx [Thu, 27 Nov 2014 22:35:32 +0000 (17:35 -0500)]
Fix: channel names are not validated
This patch ensures:
1. A channel name does not contain any '/' character, since
relative paths may be injected in the channel name
otherwise (knowing that the channel name is eventually
part of a file name)
2. A channel name does not start with a '.' character, since
trace readers (Babeltrace is one of them) could interpret
files starting with a dot as hidden files and ignore
them when opening the CTF trace
Introduce tmp_path to ensure that no code path can possibly try to free
the return value of utils_get_home_dir(). Re-using alloc_path for both
static and dynamically allocated pointer is error-prone.
Fix: Live tracing does not honor live timer after first tracefile with tracefile rotation
When we pass to the 2nd sub-file (or following sub-files) of a stream in
relayd, the live timer has no visible effect from a live reader
perspective, and then everything is flushed when we reach the following
sub-file.
This is caused by the reset of stream->total_index_received after each
tracefile rotation. It should keep on incrementing to match what is
expected by check in check_index_status():
Fix: UST subbuffers silently dropped on moderate trace traffic
Well, it looks like we really screwed up on this one.
lttng-tools commit 02b3d1769d5f8a33e4109b1e681141c9295dfda6 introduced
an important regression for lttng-ust tracing in the consumer daemon:
after reading a sub-buffer, a check has been added to see whether there
are more sub-buffers available to read, and if it is the case, it
ensures the wakeup pipe will be awakened again.
The issue lies in the use of ustctl_put_next_subbuf() in this check.
This acts as if the sub-buffer has been read, when in reality it has not
been read. It therefore trashes the data contained by this sub-buffer.
This check should use ustctl_put_subbuf(), which does not move the
consumer position.
This is a severe bug, and the fix needs to be applied to stable-2.6,
stable-2.5, and stable-2.4.
Julien Desfossez [Wed, 12 Nov 2014 23:36:17 +0000 (18:36 -0500)]
Fix: create/destroy a splice_pipe per stream
We had a per-thread splice_pipe (one for data and one for metadata), but
in case of error, we would end up filling the write side of the pipe and
never emptying it. This could lead to leaking data from one session to
the other, but also to stall the consumer trying to splice into a full
pipe.
Now we create a splice_pipe per-stream, so it is destroyed when the
session is destroyed.
David Goulet [Tue, 7 Oct 2014 19:05:48 +0000 (15:05 -0400)]
Fix: return EINVAL if agent registration fails
The errno value might be 0 thus not returning an error if so. It has
been seen with an unstable python agent code base which means it could
happen in the future if a third part decides to create an agent.
Signed-off-by: David Goulet <dgoulet@efficios.com>
In order to correctly handle the use-case where events are enabled
_after_ trace is started, and _after_ applications are already being
traced, the event should be created in a "disabled" state, so that it
does not trace events until its filter is attached.
This fix needs to be done both in lttng-tools and lttng-ust. In order to
keep ABI compatibility between tools and ust within a stable release
cycle, we introduce a new "disabled" within struct lttng_ust_event
padding (previously zeroed). Newer LTTng-UST checks this flag, and
fallback on the old racy behavior (enabling the event on creation) if it
is unset.
Therefore, old session daemon works with newer lttng-ust of the same
stable release, and vice-versa. However, building lttng-tools requires
an upgraded lttng-ust, which contains the communication protocol with
the new "disabled" field.
This patch should be backported to stable-2.4, stable-2.5, stable-2.6
branches.
David Goulet [Fri, 31 Oct 2014 17:23:29 +0000 (13:23 -0400)]
Fix: UST consumer sync all available metadata
In live mode, the sync metadata function was only working on one single
metadata stream of a given session ID. However, we can have multiple
metadata stream for the same session ID thus failing to send the data in
live mode correctly for the other streams.
This fixes it by simply iterating over all metadata stream for a session
ID and syncing them all.
Signed-off-by: David Goulet <dgoulet@efficios.com>
The issue uncovered a more serious problem. The loop on ready FDs of the
thread was exiting at each branch thus not going on all fd. This is
problematic when the thread quit pipe is triggered and when there is
also at the same time a request for metadata from the consumer since the
metadata request could have been ignored.
This patch makes sure we go through all FDs in the loop when the thread
quit pipe or the metadata fd is triggered.
Signed-off-by: David Goulet <dgoulet@efficios.com>
Julien Desfossez [Wed, 27 Aug 2014 17:59:21 +0000 (13:59 -0400)]
Fix: make sure no index is in flight before using inactivity beacons
Since the index is sent in two parts on two separate connections from
the consumer, there can be cases where we receive an inactivity beacon
between the index creation and the data reception.
This fix prevents from using the inactivity beacon if we know a data
index is coming.
Signed-off-by: Julien Desfossez <jdesfossez@efficios.com> Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: Parenthesize previous statement when adding conditions to a filter
Not parenthesizing the clauses in a filter string causes JUL events to be
traced even though they are not enabled when an enable-event command is
issued with a filter and the --loglevel-only option.
Fix: parse_prob_opts return the actual success of the function
This bug have been triggered by the mi merging and the use of a
command_ret in enable_events functions. Previously, enable_events was
reusing the ret variable for another operation and always replacing ret.
Parse_probe_event returned the last output of sscanf which represent
the number of match and not the success of the operation.
Fixes #830
Signed-off-by: Jonathan Rajotte Julien <jonathan.r.julien@gmail.com> Signed-off-by: David Goulet <dgoulet@efficios.com>
It is never locked in this function, but should be. This is triggering
spurious runtime failures on my system, where it seems that sessiond was
sometimes breaking the communication pipe with liblttng-ctl when the
unbalanced unlock is reached.
This should be backported to stable-2.4 and stable-2.5.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: get the stream_id when generating live beacons
When we send an empty index (beacon), we need to extract the stream_id
to avoid stalling the client on inactive streams on startup.
Since the live clients need to know this feature is implemented, we had
to bump the lttng-live protocol version.
This fix should be backported to stable-2.4 as well.
Fix: memory leak in lttng_enable_event_with_exclusions
lttng_enable_event_with_exclusions leaks a filter expression when
automatically generated filter statements are used. This happens when
loglevel and logger name filtering are used when enabling JUL events.
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Signed-off-by: David Goulet <dgoulet@efficios.com>
Fix: alignment problems on targets not supporting unaligned access.
Accessing floats, doubles and 64 bit int at unaligned addresses is not
supported on all configurations of arm processors and if it is it's
emulated and slow. This patch replaces direct assignments with memcpy.
Signed-off-by: Fredrik Markström <fredrik.markstrom@gmail.com> Signed-off-by: Roy Li <rongqing.li@windriver.com> Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: David Goulet <dgoulet@efficios.com>
projects / lttng-tools.git / log
