David Goulet [Wed, 18 Jun 2014 18:08:24 +0000 (14:08 -0400)]
JUL: use root logger to capture events
The JUL agent now uses the root logger ("") to capture all events. This
allows us to remove the Timer thread and cleanup a huge portion of the
code base. It simplifies a great deal the internal structure of the
agent since we don't have to monitor the Logger object anymore.
Since tracepoint filtering is done in UST, we just the LTTng handler to
the root logger and send everything to UST.
Signed-off-by: David Goulet <dgoulet@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Christian Babeux [Thu, 26 Jun 2014 15:42:28 +0000 (11:42 -0400)]
Fix: Wrong configure check for UST perf event counters context support
When building on non-x86 platforms, the build errors out with the following:
CC lttng-context-perf-counters.lo
lttng-context-perf-counters.c:95:2: error: #error "Perf event counters are only supported on x86 so far."
lttng-context-perf-counters.c: In function 'read_perf_counter':
lttng-context-perf-counters.c:114:4: warning: implicit declaration of function 'rdpmc' [-Wimplicit-function-declaration]
make[2]: *** [lttng-context-perf-counters.lo] Error 1
The configure script checks for the presence of the "perf_event.h" header to enable support for
perf events counters. However, the current implementation is only available on x86,
hence the build fails on platform where the perf header is available.
Fix this issue by detecting the architecture we are currently building and wether
to enable or not the support for perf event counters context.
Signed-off-by: Christian Babeux <christian.babeux@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
If we have a C file in an application that is meant to contain both the
instrumentation and the provider, build fails if we have more than one
provider.
Fixed by putting back definitions to the state they were when defined by
tracepoint.h after a probe provider is created. This allows the next
tracepoint provider to define its tracepoints.
David Goulet [Wed, 7 May 2014 15:33:41 +0000 (11:33 -0400)]
Fix: remove JUL loglevel filtering from the agent
The loglevel filtering is now done on the UST side setup by
liblttng-ctl. To achieve that, the agent has a new structure to support
two semantic concepts being a LTTng event and a JUL logger that have a
relation of N:1. This addition does not impact the current interfaces of
the agent.
Signed-off-by: David Goulet <dgoulet@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Move generated headers to the BUILT_SOURCES target
This fixes the out of tree build when enabling Java support. The
problem in using an LTTngUst.c target is that automake will then
assume the file is generated and thus be found in the builddir.
Using the BUILT_SOURCES target will ensure the
org_lttng_ust_LTTngUst.h and org_lttng_ust_jul_LTTngUst.h headers
are generated before LTTngUst.c is compiled.
Examples binaries in doc/examples require libs in liblttng-ust/.libs/,
and those libs require other libs in the same directory. For instance
liblttng-ust.so uses liblttng-ust-tracepoint.so symbols, so the latter
is needed to properly link example programs. Currently, ld is given
the lib dir only via -rpath (used for linking executables dependencies)
but not via -rpath-link (used for linking libs dependencies).
When compiling regularly, this does not seem to be a problem (maybe ld
is smart enough). However when cross-compiling with the
arm-linux-gnueabihf toolchain, -rpath-link is needed otherwise linking
fails with:
arm-linux-gnueabihf/bin/ld: warning: liblttng-ust-tracepoint.so.0, needed by ../../../liblttng-ust/.libs//liblttng-ust.so, not found (try using -rpath or -rpath-link)
This patch adds -rpath-link to doc/examples/Makefile.am.
Fix: disable liblttng-ust-dl if dlinfo is not available in C library
According to uClibc commit [1], dlinfo is not available in recent uClibc
(>0.9.33), but available in older version of uClibc (<=0.9.33) whith a
different prototype than glibc.
dlinfo used by liblttng-ust-dl require RTLD_DI_LINKMAP that is not
available in uClibc.
To be able to use LTTng UST with uClibc, we need to disable the Dynamic
Linker Tracing functionality [2] if RTLD_DI_LINKMAP is not detected.
lib_ring_buffer_write_commit_counter()'s 'buf_offset' argument should
contain offset of beginning of area used by the record being comitted.
However, lib_ring_buffer_commit() passes ctx->buf_offset, that gets
advanced by lib_ring_buffer_write() and thus points to just-after-
end-of-record at lib_ring_buffer_commit() time. This causes
lib_ring_buffer_write_commit_counter() to return without changing
commit_hot[idx].seq, due to
if (unlikely(subbuf_offset(offset - commit_count, chan)))
return;
Since after-crash data extraction tool checks 'seq' field to find out
how much data is in buffer, this results into inavailability of
data from partially-filled subbuffer for after-crash analysis.
This patch modifies lib_ring_buffer_write_commit_counter() and all its
callers to pass and expect the end of the area. So code works as it
should, and complete information becomes visible in crash dump.
[ Fix ported from lttng-modules. Changelog inspired from Nikita
Yushchenko's original patch. ]
Fix: .split() the CC environment variable in lttng-gen-tp
The CC variable might contain command line arguments which lttng-gen-tp
currently does not handle. This fix ensures that the arguments are
properly passed on to the compiler binary as if a normal Makefile
was used.
Fix: disable liblttng-ust-dl if dlinfo is not available in C library
According to uClibc commit [1], dlinfo is not available.
To be able to use LTTng UST with uClibc, we need to disable
the Dynamic Linker Tracing functionality [2].
Jesper Derehag [Thu, 27 Mar 2014 07:57:06 +0000 (08:57 +0100)]
Fix: python invocation through env
This modification calls the interpreter through env instead of
directly, which should be more portable for those distros which do not install
python into /usr/bin/.
Building LTTng-UST with --disable-shared compiles fine, but the
resulting installed static libraries silently fails to trace, because
tracepoint fails to dlopen liblttng-ust-tracepoint.so. So don't allow
this unsupported configure option.
Fix: liblttng-ust-libc-wrapper recursive use of calloc
When built with URCU with --disable-compiler-tls, URCU tls-compat.h uses
calloc in its TLS compat layer. This is used by RCU read-side, which is
used by tracepoint. So using a tracepoint in calloc triggers an infinite
recursion, since its first use of the TLS (with TLS compat) calls
calloc.
Fix this issue by keeping a per-thread nesting counter, and as soon as
we are allocating memory from a context nested within the memory
allocator, don't trace.
Don't trace from the static allocator: keep it as simple as possible,
since this is our fallback.
Lars Persson [Wed, 12 Mar 2014 09:28:49 +0000 (10:28 +0100)]
Use autoconf AM_MAINTAINER_MODE
Give distribution maintainers the option to skip rebuilding
autoconf and automake generated files. The default behaviour
is still to have the rebuild rules enabled.
Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Paul Woegerer [Fri, 28 Feb 2014 09:02:00 +0000 (10:02 +0100)]
Turn base address dump into experimental feature
Instead of having base address state dump enabled by default make it
necessary to explicitly enable it with environment variable
LTTNG_UST_WITH_EXPERIMENTAL_BADDR_STATEDUMP.
Documentation is updated to reflect this change and explain about the
experimental nature of this feature.
Signed-off-by: Paul Woegerer <paul_woegerer@mentor.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
David Goulet [Thu, 27 Feb 2014 16:53:22 +0000 (11:53 -0500)]
Fix: dynamically fetch the session daemon port
When connecting to the session daemon, fetch the port at each try. This
moves the read port file functions to the TCP session daemon client
where the connect happens.
If the port file is not found, simply retry 3 seconds later. Also, this
adds a timeout to the acquire semaphore of 3 seconds.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: David Goulet <dgoulet@efficios.com>
David Goulet [Thu, 27 Feb 2014 15:06:52 +0000 (10:06 -0500)]
Fix: JUL agent connect to user and root sessiond
In order to achieve such a thing, two tracepoints are used where one is
for the regular user and the other one for root. This is to avoid
duplicating the payload in the user and root traces.
Furthermore, if a root port is found, a new thread is started to handle
the second session daemon.
Paul Woegerer [Tue, 25 Feb 2014 09:47:00 +0000 (10:47 +0100)]
Fix: Dump executable base-address with readlink
The previous approach only worked if the traced executable was invoked
via its fully qualified path. Using readlink to determine the full
qualified path of the traced executable works reliably even when the
traced executable is started via PATH lookup.
Signed-off-by: Paul Woegerer <paul_woegerer@mentor.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Found by Coverity:
CID 1090602 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking "stream" suggests that it may be null,
but it has already been dereferenced on all paths leading to the check
CID 1021261 (#1 of 1): Argument cannot be negative (NEGATIVE_RETURNS)10.
negative_returns: "sysconf(30)" is passed to a parameter that cannot be
negative.
Fix: work-around glibc lying about dlsym()/dlerror() leafness
Especially in the LTTng-UST malloc instrumentation, we run into the
following situation:
1) Our calloc wrapper is called,
2) we setup the static allocator,
3) we call dlsym() to lookup the symbol of the real allocator,
4) dlsym() calls into calloc(), which is overridden by our own wrapper.
Our calloc does not see that the static allocator has been set,
because the stores setting up the static allocator have been optimized
away by gcc-4.8 (in O2), because the dlsym() prototype declares it
with the "leaf" attribute, and thus we end up doing an infinite
recursion, and eventually a segmentation fault.
Thanks to Alexander Monakov for pointing out the culprit of this glibc
bug.
calloc and realloc wrt dlsym and dlerror can trigger segmentation
faults. Ensure that we fully populate the allocator symbols all at once,
and also ensure that we use the static allocator while doing the dlsym
lookups.
David Goulet [Fri, 7 Feb 2014 20:09:12 +0000 (15:09 -0500)]
Fix: add LTTngEvent class to fix delayed logger
This commit introduces a new object called LTTngEvent that represent a
LTTng event containing some attributes, for now loglevel data.
Instead of moving event string name around, this object is created once
and kept in the log handler so once a record is publish we can match
attributes such as loglevels.
This has to be done in order to fix the issue where we have a Logger
that appears later on during runtime (with the timer that poll every 5
seconds). With a created event object we can lookup back the event
attributes and enabled it accordingly. Same goes with the * (all events)
where we now keep the loglevel values process wide so we can force the
new events to use it.
Signed-off-by: David Goulet <dgoulet@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Make sure wait/wakeup stream and channel FDs are closed at teardown.
This led to FD leaks on the consumer daemon when the relay daemon
disconnects unexpectedly.
Recently, commits to fix SDT issues with extern C
(https://bugs.lttng.org/issues/597) brougt in compile errors when the
tracepoint is defined in the same file where the tracepoint provider is
created.
This was due to the presence of extern C guards in tracepoint-event.h, a
header dedicated to tracepoint probe provider compilation. After commits
"Tracepoint probes don't need extern C", it should have gone away. This
is the main fix done by this patch.
This patch also adds missing extern C guards in ust-error.h and
ust-events.h.
Would deal with spaces in the env. var. if there are any. It does not
seem to be important in practice (currently), because automake seems to
fail on CC including spaces at configure time.
Make sure that the ust_baddr_statedump probe is registered prior to
using the tracepoint in lttng_ust_baddr_statedump(). This fix solves the
issue that in rare cases the very first ust_baddr_statedump events were
missing.
Use a reference counting approach that allows constructors/destructors
of the probe to be called many times, as long as the number of calls to
constructor matches the number of calls to destructor.
Reported-by: Paul Woegerer <paul_woegerer@mentor.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Paul Woegerer [Tue, 10 Dec 2013 13:07:51 +0000 (14:07 +0100)]
Fix: baddr_statedump tracepoint registration
Ensure baddr_statedump tracepoint registration is completed prior to
using the tracepoint in lttng_ust_baddr_statedump().
Make liblttng-ust-dl robust for explicit baddr_statedump tracepoint
deregistration in lttng_ust_cleanup() (prevent dlopen/dlclose to get
traced if ust_baddr tracepoints are not available).
Signed-off-by: Paul Woegerer <paul_woegerer@mentor.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix RCU races by ensuring every UST source file using RCU read-side lock
is marked as _LGPL_SOURCE. The dynamic binding to urcu-bp relies on the
dynamic loader, and it seems not to behave well when used from
constructors.
Use Userspace RCU with this commit to completely fix baddr races:
"Fix: urcu-bp interaction with threads vs constructors/destructors"
It should use lib_ring_buffer_read_offset_address() to get the packet
being read, rather than lib_ring_buffer_offset_address(), which is only
meant to be used when writing to the packet.
Compile liblttng-ust-baddr c files into liblttng-ust
Move them into liblttng-ust/, where they are now compiled.
This is to ensure we don't rely on statically linked libs (and
associated constructor problems), and that we don't install a shared
object in the system needlessly.
By using the timestamp sampled at space reservation when the packet is
being filled as "end timestamp" for a packet, we can ensure there is no
overlap between packet timestamp ranges, so that packet timestamp end <=
following packets timestamp begin.
Overlap between consecutive packets becomes an issue when the end
timestamp of a packet is greater than the end timestamp of a following
packet, IOW a packet completely contains the timestamp range of a
following packet. This kind of situation does not allow trace viewers
to do binary search within the packet timestamps. This kind of situation
will typically never occur if packets are significantly larger than
event size, but this fix ensures it can never even theoretically happen.
The only case where packets can still theoretically overlap is if they
have equal begin and end timestamps, which is valid.
David Goulet [Wed, 20 Nov 2013 16:35:35 +0000 (11:35 -0500)]
JUL: fix enable all event for delayed Logger
This adds a HashMap containing the enabled Logger names (and wildcard
'*'). This is used to make sure we don't enable twice the same Logger
for the '*' event name (enable all -a).
Signed-off-by: David Goulet <dgoulet@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
projects / lttng-ust.git / log
