Antoine Busque [Wed, 20 Apr 2016 17:09:07 +0000 (13:09 -0400)]
Rename statedump and dl events and fields
The current names of the `lttng_ust_statedump:soinfo` event, as well
as its field `sopath` both refer exclusively to shared objects (so),
although the event applies to any executables, including
position-independent executables (PIE), as well as shared objects.
Thus, this patch changes the name of the event to `bin_info` and the
field to `path`, to avoid any confusion.
For consistency, the `sopath` field in the `lttng_ust_dl:dlopen` event
is also renamed to `path`, although dlopen only applies to shared
objects.
Signed-off-by: Antoine Busque <abusque@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Antoine Busque [Fri, 15 Apr 2016 17:18:04 +0000 (13:18 -0400)]
Tests: add tests for lttng_ust_elf_is_pic
This adds tests for the lttng_ust_elf_is_pic function used to tell
whether an executable is position independent code or not. Three
sample executables are used, one non-PIC executable, one PIE, and a
PIC shared object.
Signed-off-by: Antoine Busque <abusque@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Antoine Busque [Wed, 13 Apr 2016 21:31:57 +0000 (17:31 -0400)]
Add is_pic field to statedump soinfo event
This field indicates whether the executable or library is position
independent code (PIC). The field is not added to the similar dlopen
event from liblttng-ust-dl because in that case all dlopened libraries
are necessarily PIC.
This allows a posteriori analyses to be performed without having to
read the executable file to know whether adresses are relative to the
base address or absolute.
Signed-off-by: Antoine Busque <abusque@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: rename liblttng-ust-agent to lttng-ust-agent-all
Rename liblttng-ust-agent to lttng-ust-agent-all to respect the new
jar file naming scheme, but keep a symbolic link from liblttng-ust-agent
to lttng-ust-agent-all to keep backwards compatibility.
The UST 2.7 java agent LTTngAgent class has a non-static dispose method.
This class is kept in 2.8 for backwards compatibility purposes. Keep
this API unchanged.
The built troff man pages should be distributed in a release
tarball. When building from a release tarball, the tools (asciidoc
and xmlto) are not strictly needed, unless a man page source is
modified/removed, in which case:
if the tools existed at configure time:
rebuild/update man page
otherwise:
show an error message which indicates why the target
cannot be built because the tools are missing
When building from the Git repository, and when --enable-man-pages
is used, the tools are required at configure time.
The incentive for this change is to make the man pages easier to
write and maintain, AsciiDoc being far more easy to read and write
than pure troff, as well as enable rich HTML man page generation
from the intermediate DocBook XML file to publish man pages with
working internal/external links and style improvements on the
LTTng website. This also makes LTTng-UST man pages conform to the
LTTng-tools ones which use the same mechanism.
The following "redirection" man pages are also added:
They all redirect to lttng-ust(3). They are always distributed,
but only installed when lttng-ust(3) is also installed (which is
when --enable-man-page exists at configure time).
See the new doc/man/README.md file for more details about the
new files and macros to use in the AsciiDoc man page source files.
This patch also contains various content fixes and updates of the
LTTng-UST man pages. Some new content is based on the online LTTng
documentation.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
This has been detected in the lttng-modules port of the filter
interpreter by Coverity. The intent of the code in UST is similar, and
we can find the same dead code, although Coverity may not see it as dead
code because it cannot prove that the string is not modified between the
two uses. Since we know it is not modified, remove the dead code.
will print a range of 0 ... -1 in the generated CTF metadata, which does
not reflect signedness of the values.
Also, struct ustctl_enum_entry is missing a LTTNG_PACKED attribute,
which is against our protocol rules.
This change needs to be pushed in locked-step into lttng-tools and
lttng-ust, since it breaks the protocol between the two when UST uses
the new enumeration type (introduced in 2.8.0-rc1).
Assertions in the lttng-ust-comm init function are slightly too harsh
for their own good. In situations involving incoherent seccomp profiles
(e.g. accepting futex, poll, nanosleep, clock_nanosleep, but not
restart_syscall), unexpected errno values can be returned by
sem_timedwait.
Print an error in those situations, but let the application proceed.
Calling this function from an instrumented program allows disabling
tracepoint destructors. This allows threads to continue calling
tracepoint code even after the tracepoint destructors have run. This is
needed for applications that exit without joining all their threads.
Fix: handle backward probe compatibility for application contexts
Fix segmentation fault of applications built against lttng-ust 2.7,
linked against lttng-ust 2.8-pre when tracing is active. We need to
consider backward ABI compability here, which can be done by using
a dummy context in place of an application context when recording an
event. Basically, application contexts won't be saved into events
generated by a lttng-ust 2.7 probe provider: those will appear as empty
contexts.
15:07:12 lttng_ust_context.c: In function 'Java_org_lttng_ust_agent_context_LttngContextApi_registerProvider':
15:07:12 lttng_ust_context.c:377:17: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
15:07:12 provider_ref = (jlong) provider;
Pass the Java app context information using two separate arrays
Instead of using one array with length limits for strings, we can
pass two separate arrays: the first will continue to contain fixed-
size entries, but instead of 256 bytes for strings, we will use
4-byte offsets to a second array, which will contain only those
variable-length strings.
The advantage is that we pass less bytes overall, and we don't
limit the context names or values to 256 bytes anymore.
Fix: Correctly report filter notifications on Java agent teardown
If a Java agent gets disposed, it should not just clear() all its
tracked event rules: it should first send corresponding filter change
notifications indicating that these rules are not tracked anymore.
This fixes a problem where if event rules were still enabled on agent
tear down, the filter notifier's own tracked events would become out
of sync.
Fix: Ensure the Java JUL messages are correctly formatted
It is possible for log records to contain messages that need some
formatting, for example if the string contains localized elements
or if the log(Level, String, Object[]) method is used.
In these cases, we need to make sure to format the string and not
pass the "raw" string to the tracepoint.
This only applies to the JUL API. log4j 1.2.x did not handle such
formatting, although log4j 2.x does.
Philippe Proulx [Fri, 27 Nov 2015 17:39:51 +0000 (12:39 -0500)]
Refactor Python agent build and install
Since the Python agent's tracepoint provider,
liblttng-ust-python-agent, does not depend on Python, it can
always be built and installed alongside LTTng-UST.
The Python package of this agent is completely independent
from the rest of the tree, thus it is isolated in its own
directory. This also eases the creation of distribution
packages because the packager can selectively build and
install the Python package without also building/installing the
tracepoint provider.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
When adding large context (e.g. callstack), headers larger than 256
bytes cause discrepancy between calculated size and size written into
the trace buffers. This generates a corrupted trace and triggers a
warning in ring buffer backend, which triggers a safety net disabling
tracing for the current channel.
Considering the Agent Protocol is bumped to v2.0 as of 2.8.x,
this patch revisits the unfortunate decision of communicating
in host-endianness from the session daemon to the agents, and
in big endian from the agents to the session daemon.
This change does not affect the Python agent which was erroneously
(although quite reasonably) assuming communications were occurring
in network endianness.
This issue does not affect versions 2.7 and below because the loglevel
was not used.
Fix: Return the correct list of available Java events
The "lttng list -j/-l" command should list the events that are currently
offered by Java application and available to be enabled.
Due to some confusion in the implementation of the corresponding agent
command response, it was actually returning the list of events that were
enabled in the tracing session.
Rectify this by sending the list of loggers of the corresponding domain
that have one or more LTTng log handlers attached. The interface method
was also renamed from listEnabledEvents() to listAvailableEvents() to
make it more representative.
Add filter change notification mechanism to the Java agent
Java applications can now register to receive notifications of event
filtering rules being changed in the tracing session. This can be
used to implement application-specific filtering on the Java side,
to reduce the amount of events sent through JNI.
To do so, they need to implement a IFilterChangeListener and register
it to the FilterChangeNotifier. The listener's callbacks will
be invoked by the LTTng agent when the tracing session(s) change.
A new example file is provided to demo this usage.
Instead of just tracking which event names are enabled in the tracing
session, we can track the complete name/filter/loglevel tuple. This
allows the same event name to be specified multiple times but with
different parameters.
Right now the sessiond does not send the filter string, a new protocol
version will be required to do so. But we can prepare for it in the
meantime.
The agent will continue to use the event names to decide if events
should be sent through JNI or not. However, full rules will be useable
for other purposes, like the upcoming filter notifications.
Introduce a new client listener interface for the Java agent
Decouple the TCP client from the implementation of the LTTng Java agent.
Instead of using AbstractLttngAgent directly, the TCP client (and the
command subclasses) can deal with the new ILttngTcpClientListener
interface. The agent will implement this interface.
This will also allow easier testing of the TCP client and its protocol,
since test classess can now implement their own listener and verify the
contents of each command.
This allows defining a default behavior for the getBytes() method.
That behavior consists of only returning the integer return code,
which is what most (but not all) subclasses use.
Mikael Beckius [Tue, 12 May 2015 09:04:34 +0000 (11:04 +0200)]
Fix: live timer calculation error
There is an calculation error for live timer. Variable
chan->switch_timer_interval is based on microsecond, and it is not right
to assign chan->switch_timer_interval mod 1000000 to var tv_nsec which
is based on nanosecond.
Signed-off-by: Mikael Beckius <mikael.beckius@windriver.com> Signed-off-by: Jianchuan Wang <jianchuan.wang@windriver.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Stelios Bounanos [Wed, 14 Oct 2015 16:31:36 +0000 (17:31 +0100)]
Fix: Don't (re)define STAP_PROBEV
Define a new LTTNG_STAP_PROBEV macro to avoid clobbering STAP_PROBEV or
emitting unwanted sdt probes when lttng-ust has been built without sdt
support.
Fix: Argument with 'nonnull' attribute passed null
Reported by scan-build
API Argument with 'nonnull' attribute passed null libringbuffer
/ring_buffer_backend.c 380
API Argument with 'nonnull' attribute passed null libringbuffer
/ring_buffer_backend.c 420
projects / lttng-ust.git / log
