The following scenario could lead to a segmentation fault in
applications when the sessiond disappears or when the application try to
exit. This is caused by incorrect handling of reference counts.
This can happen in very particular race scenario, described as follows:
1) The sessiond asks for "release" of one or more objects (e.g. a
session object), but _without_ asking for release of _all_ objects
referencing the session.
2) The application exits, thus calling objd_table_destroy(). It walks on
all objects, decrementing their reference count, freeing memory when
their reference count reaches "1".
However, here is the issue: since "release" has already been performed
by sessiond on the session object, this extra reference count unref
performed by objd_table_destroy() can make the session object disappear
while it is still needed by either the channel object or the enabler
object. Therefore, we can experience a segmentation fault when we try to
unref and free the channel or enabler objects within
objd_table_destroy().
Fix this issue by adding the concept of an "owner reference". Only
objd_table_destroy(), lttng_ust_objd_table_owner_cleanup(), "release"
commands, and failure paths of object creation are allowed to decrement
the owner reference. We restrict objd_table_destroy() and
lttng_ust_objd_table_owner_cleanup() to _only_ decrement refcount of
objects _if_ their owner reference is still held.
The filter feature added a direct dependency of probes providers against
urcu-bp .so, while linking them against liblttng-ust should suffice. Fix
this by using the tracepoint.h wrapper for rcu_dereference().
Speed up process startup for applications with large number of
tracepoints (e.g. 16k in J9 vm) by increasing the tracepoint.c hash
table size from 64 to 4096.
Scalability fix for many events: event hash table size
Increase number of buckets for event hash table (per session) from 64 to
4096. This improves process startup time for J9 vm (with 16k
tracepoints) very significantly.
Speed up probe registration for large amount of events
LTTng-UST probe registration is O(n^2). I actually left a comment that
describes this, also implying that we can improve this if it becomes an
issue.
I've had a report from Yang Wang, who works on instrumenting the J9 VM,
that O(n^2) does not agree well with 16000 probes and tracepoints.
It appears that lttng_probe_register() is being too paranoid for its own
good. There are now many things that are guaranteed by the way probe
providers are being built.
We actually need to keep a check that no provider with the same name has
been registered (O(n) on the number of registered providers, could be
improved with a hash table if it ever becomes necessary).
Use an assert to check that each event name starts with its own provider
name (it would be an internal error within the provider if it's not the
case). (O(n) on the number of events within a provider)
The rest is just useless, so remove this O(n^2) check.
While we are there, remove the now unused
lttng_event_get()/lttng_event_put() functions.
Reported-by: Yang Wang <yangw.wang5@unb.ca> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Introduce hash table for lttng_create_event_if_missing()
lttng_create_event_if_missing() takes a lot of CPU time with stress-test
applications containing 1000 different TRACEPOINT_EVENT() and 1000
individual tracepoint() call-site.
With tracing disabled:
time ./AppWith1000_lines_TP 0
real 0m2.487s
user 0m2.424s
sys 0m0.000s
Introducing this hash table cuts the overhead very significantly when
tracing is enabled:
Samuel Martin [Sun, 13 Jan 2013 16:40:10 +0000 (11:40 -0500)]
Fix: don't build C++ example if a C++ compiler isn't available
By default lttng-ust builds a hello.cxx C++ example that demonstrates
the usage of the userspace tracing library in a C++ program.
Unfortunately, when no C++ support is available, the build of lttng-ust
fails just because of this example code. So we make the compilation of
this code conditional on whether a working C++ compiler was found.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Pack structures in comm protocol between UST and sessiond
Ensure robustness with respect to 32-bit vs 64-bit apps vs sessiond.
Since we are updating the ABI, change the order of overwrite field in
channel and channel attributes, to remove some unneeded padding.
This breaks compatibility between sessiond 2.1 and ust 2.0 (and
vice-versa), but sessiond refuses applications with version number that
does not match.
ltt_event -> lttng_event mass rename
Rename ltt_chan -> lttng_chan
Rename ltt_session -> lttng_session
Rename enum abstract_types to enum lttng_abstract_types
Rename ltt_transport to lttng_transport
Rename rest of ltt_ prefixes to lttng_
Complete file and symbol renames from LTT/ltt to LTTNG/lttng
Finish ltt->lttng symbol conversion
Reviewed-by: David Goulet <dgoulet@efficios.com> Reviewed-by: Christian Babeux <christian.babeux@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Conditionally disable tests requiring shared libs support
When building lttng-ust with shared library support explicitly
disabled (e.g.: ./configure --disable-shared), libtool fail with
a fatal error:
CC tp.lo
CC tp2.lo
CCLD liblttng-ust-provider-ust-tests-demo.la
libtool: link: can not build a shared library
libtool: link: See the libtool documentation for more information.
libtool: link: Fatal configuration error.
The build should not fail because some tests require explicit shared
library support, instead they should be skipped.
This patch detect that the --disable-shared flag was passed to the
configure script and toggle the "NO_SHARED" Automake variable.
Thus, the tests that require explicit shared library support can
be skipped when the NO_SHARED variable is true.
[ Edit by Mathieu Desnoyers: add "" in configure.ac to follow the local
coding style. ]
Signed-off-by: Christian Babeux <christian.babeux@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Hollis Blanchard <hollis_blanchard@mentor.com> wrote:
> I seem to have hit a little problem with a "hello world" test app and
> lttng-ust 2.0.3. lttng-ust.git seems to be affected as well. Basically,
> I created a single UST tracepoint, but as soon as I run "lttng
> enable-event -u -a", my app segfaults. The problem seems to be that when
> creating the event to pass to ltt_event_create(), we try to memcpy the
> full 256 bytes of name. However, the name might be shorter, and if we
> get unlucky it falls within 256 bytes of the segment boundary...
Fixing the 3 sites where this issue arise. Manually inspecting all
memcpy in the UST code returned by grep did the job.
Christian Babeux [Sat, 29 Sep 2012 17:37:40 +0000 (13:37 -0400)]
Fix: reloc offset validation error out on filters with no reloc table
The reloc table is currently appended at the end of the bytecode data.
With this scheme, the reloc table offset will be equal to the length
of the bytecode data.
Val. Operator
---- --------
0x40 (FILTER_OP_LOAD_STRING)
0x6D m
0x79 y
0x53 S
0x74 t
0x72 r
0x69 i
0x6E n
0x67 g
0x00 \0
0x40 (FILTER_OP_LOAD_STRING)
0x79 y
0x6F o
0x75 u
0x72 r
0x53 S
0x74 t
0x72 r
0x69 i
0x6E n
0x67 g
0x00 \0
0x0C (FILTER_OP_EQ)
0x01 (FILTER_OP_RETURN)
In this case, we see that the reloc table offset (24) is indeed equal to
the length of the bytecode (24), but the reloc table is _empty_. Thus,
the reloc_offset received in handle_message() will be equal to the
data_size and will be wrongly flagged as not within the data even thought
the filter is entirely valid.
The fix is to simply allow a reloc_offset to be equal to the data_size.
Fixes #342
Signed-off-by: Christian Babeux <christian.babeux@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
The main issue is that get_wait_shm() bypass the fork() wrapper (with
lttng_ust_nest_count), which is responsible for holding the UST mutex
across fork(). Therefore, when exiting the context of the child process,
we execute the destructor, which try to grab the UST mutex, which might
be in pretty much any state.
Given that we don't want this process to try to register to
lttng-sessiond (because this is internal to lttng-ust), we might want to
let it skip the destructor execution. This would actually be the easiest
way out.
Fix: Filter ABI changes to support FILTER_BYTECODE_MAX_LEN (65536)
In order to support the filter bytecode maximum length (65536 bytes),
the lttng_ust_filter_bytecode len field type must be able to
hold more than a uint16_t. Change the field type to a uint32_t.
Also, since the relocation table is located at the end of the actual
bytecode, the reloc_table_offset (reloc_offset in ust-abi) field must
support offset values larger than 65535. Change the field type to a
uint32_t. This change will allow support of relocation table appended
to larger bytecode without breaking the ABI if the need arise in the
future.
Both changes currently breaks the filter ABI, but this should be a
reasonable compromise since the filtering feature has not been
released yet.
Signed-off-by: Christian Babeux <christian.babeux@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
projects / lttng-ust.git / log
