lttng-ust:stable-2.1

Last commit made on 2014-02-05
Get this branch:
git clone -b stable-2.1 https://git.launchpad.net/lttng-ust

Branch merges

Branch information

Name:
stable-2.1
Repository:
lp:lttng-ust

Recent commits

0fa0e9d... by Mathieu Desnoyers

Fix: liblttng-ust-fork Makefile flags mismatch

Signed-off-by: Mathieu Desnoyers <email address hidden>

b53fa12... by Mathieu Desnoyers

Version 2.1.4

Signed-off-by: Mathieu Desnoyers <email address hidden>

4a4d379... by Mathieu Desnoyers

Fix: ring buffer: get_subbuf() checks should be performed on "consumed" parameter

This triggers lots of false-positive -EAGAIN errors in flight recorder
snapshots.

Reported-by: Julien Desfossez <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1039e1c... by Mathieu Desnoyers

Fix: SWITCH_FLUSH new sub-buffer checks

The SWITCH_FLUSH, when performed on a completely empty sub-buffer, was
missing some checks (imported from space reservation).

Signed-off-by: Mathieu Desnoyers <email address hidden>

8fe67e2... by Mathieu Desnoyers

Fix: ring buffer: handle concurrent update in nested buffer wrap around check

With stress-test loads that trigger sub-buffer switch very frequently
(small 4kB sub-buffers, frequent flush) in lttng-modules, we currently
observe this kind of warnings once every few minutes:

[65335.896208] ring buffer relay-overwrite-mmap, cpu 5: records were lost. Caused by:
[65335.896208] [ 0 buffer full, 1 nest buffer wrap-around, 0 event too big ]

It appears that the check for nested buffer wrap-around does not take
into account that a concurrent execution contexts (either nested for
per-cpu buffers, or from another CPU or nested for global buffers) can
update the commit_count value concurrently.

What we really want to do with this check is to ensure that if we enter
a sub-buffer that had an unbalanced reserve/commit count, assuming there
is no hope that this gets rebalanced promptly, we detect this and drop
the current event. However, in the case where the commit counter has
been concurrently updated by another reserve or a switch, we want to
retry the entire reserve operation.

One way to detect this is to sample the reserve offset twice, around the
commit counter read, along with the appropriate memory barriers.
Therefore, we can detect if the mismatch between reserve and commit
counter is actually caused by a concurrent update, which necessarily has
updated the reserve counter.

Signed-off-by: Mathieu Desnoyers <email address hidden>

14459b4... by Mathieu Desnoyers

Fix: handle writes of length 0

lib_ring_buffer_write() could be passed a length of 0. This typically
has no side-effect as far as writing into the buffers is concerned,
except for one detail: in overwrite mode, there is a check to make sure
the sub-buffer can be written into. This check is performed even if
length is 0. In the case where this would fall exactly at the end of a
sub-buffer, the check would fail, because the offset would fall exactly
at the beginning of the next sub-buffer.

Signed-off-by: Mathieu Desnoyers <email address hidden>

66cdd4c... by Mathieu Desnoyers

Version 2.1.3

Signed-off-by: Mathieu Desnoyers <email address hidden>

ecf1105... by Mathieu Desnoyers

Tracepoint.h: replace assertion by fprintf and abort()

Signed-off-by: Mathieu Desnoyers <email address hidden>

c2dfb43... by Mathieu Desnoyers

Fix: tracepoint.h incorrect assumption about constructor order

Incorrect assumption about constructor execution order can trigger a
segfault when trying to execute tracepoint_register_lib.

Signed-off-by: Mathieu Desnoyers <email address hidden>

de774d1... by Mathieu Desnoyers

Fix: tracepoint instrumentation constructor order issue

If the linker decides to run a constructor from a tracepoint probe
before the constructor from the application, a recent modification
(commit 558b9d86247004f8e9bbaf8c982f3b2b182093d1) allowed that the wrong
constructor execution order could prohibit the program's tracepoints
from being registered.

Fix this by making two separate constructors.

Fixes #487

Signed-off-by: Mathieu Desnoyers <email address hidden>