7 days agoFix: Pointers are rejected by integer element compile time assertion for array and... master
Mathieu Desnoyers [Fri, 20 May 2022 16:00:08 +0000 (12:00 -0400)] 
Fix: Pointers are rejected by integer element compile time assertion for array and sequence

commit 2df82195d140b ("Add compile time assertion that array and
sequence have integer elements") introduced a check to validate that
sequences and arrays only contain integers. This was meant to refuse
arrays of double/float which are not supported.

However, as a side-effect, this also refuses arrays and sequences of
pointers, which were accepted prior to lttng-ust 2.13.

Introduce a lttng_ust_is_pointer_type() and use it in the array/sequence
type validation. The trick here is to use the fact that a difference
between two pointers in C is an integer. Therefore, we can validate that
an argument type is a pointer similarly to C++ is_pointer.

Signed-off-by: Mathieu Desnoyers <>
Fixes: #1355
Change-Id: I7c96d24ab68fb711f85eccdb781a3c513b45c5dc

9 days agoFix: statedump: invalid read during iter_end
Jonathan Rajotte [Tue, 17 May 2022 18:09:42 +0000 (14:09 -0400)] 
Fix: statedump: invalid read during iter_end


Using a modified doc/examples/easy-ust/sample.c and dummy shared objects:

  int main(int argc, char **argv)
   int i = 0;

   void *handle_cat;
   void *handle_dog;
   void (*func_print_name_cat)(const char*);
   void (*func_print_name_dog)(const char*);

   handle_dog = dlopen("./", RTLD_NOW);
   handle_cat = dlopen("./", RTLD_NOW);

   *(void**)(&func_print_name_dog) = dlsym(handle_dog, "print_name");
   *(void**)(&func_print_name_cat) = dlsym(handle_cat, "print_name");

   for (i = 0; i < 5; i++) {
   tracepoint(sample_component, message, "Hello World");

   printf("Run `lttng regenerate statedump. Press enter \n");

   printf("Run `lttng regenerate statedump. Press enter \n");


   return 0;

On lttng side:

 lttng create
 lttng enable-event -u -a
 lttng start

 valgrind sample

 Issue `lttng regenerate statedump` as the app suggest.

The second `lttng regenerate statedump` results in:

 ==934747== Invalid read of size 8
 ==934747==    at 0x48BA90F: iter_end (lttng-ust-statedump.c:439)
 ==934747==    by 0x48BAD73: lttng_ust_dl_update (lttng-ust-statedump.c:586)
 ==934747==    by 0x48BADC0: do_baddr_statedump (lttng-ust-statedump.c:599)
 ==934747==    by 0x48BAE62: do_lttng_ust_statedump (lttng-ust-statedump.c:633)
 ==934747==    by 0x489F820: lttng_handle_pending_statedump (lttng-events.c:969)
 ==934747==    by 0x488C000: handle_pending_statedump (lttng-ust-comm.c:717)
 ==934747==    by 0x488DCF7: handle_message (lttng-ust-comm.c:1110)
 ==934747==    by 0x48905EA: ust_listener_thread (lttng-ust-comm.c:1756)
 ==934747==    by 0x4B62608: start_thread (pthread_create.c:477)
 ==934747==    by 0x4A4D162: clone (clone.S:95)
 ==934747==  Address 0x4c4ea88 is 4,152 bytes inside a block of size 4,176 free'd
 ==934747==    at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/
 ==934747==    by 0x48B9588: free_dl_node (lttng-ust-statedump.c:123)
 ==934747==    by 0x48BA90A: iter_end (lttng-ust-statedump.c:450)
 ==934747==    by 0x48BAD73: lttng_ust_dl_update (lttng-ust-statedump.c:586)
 ==934747==    by 0x48BADC0: do_baddr_statedump (lttng-ust-statedump.c:599)
 ==934747==    by 0x48BAE62: do_lttng_ust_statedump (lttng-ust-statedump.c:633)
 ==934747==    by 0x489F820: lttng_handle_pending_statedump (lttng-events.c:969)
 ==934747==    by 0x488C000: handle_pending_statedump (lttng-ust-comm.c:717)
 ==934747==    by 0x488DCF7: handle_message (lttng-ust-comm.c:1110)
 ==934747==    by 0x48905EA: ust_listener_thread (lttng-ust-comm.c:1756)
 ==934747==    by 0x4B62608: start_thread (pthread_create.c:477)
 ==934747==    by 0x4A4D162: clone (clone.S:95)
 ==934747==  Block was alloc'd at
 ==934747==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/
 ==934747==    by 0x48B936A: zmalloc (helper.h:27)
 ==934747==    by 0x48B936A: alloc_dl_node (lttng-ust-statedump.c:85)
 ==934747==    by 0x48B98F7: find_or_create_dl_node (lttng-ust-statedump.c:184)
 ==934747==    by 0x48BA205: extract_baddr (lttng-ust-statedump.c:339)
 ==934747==    by 0x48BABC6: extract_bin_info_events (lttng-ust-statedump.c:528)
 ==934747==    by 0x4A8D2F4: dl_iterate_phdr (dl-iteratephdr.c:75)
 ==934747==    by 0x48BAD4C: lttng_ust_dl_update (lttng-ust-statedump.c:583)
 ==934747==    by 0x48BADC0: do_baddr_statedump (lttng-ust-statedump.c:599)
 ==934747==    by 0x48BAE62: do_lttng_ust_statedump (lttng-ust-statedump.c:633)
 ==934747==    by 0x489F820: lttng_handle_pending_statedump (lttng-events.c:969)
 ==934747==    by 0x488C000: handle_pending_statedump (lttng-ust-comm.c:717)
 ==934747==    by 0x488DCF7: handle_message (lttng-ust-comm.c:1110)


Nodes can be removed during the `cds_hlist_for_each_entry_2` iteration which
is not meant to be used when items are removed within the traversal.


Use `cds_hlist_for_each_entry_safe_2`.

Change-Id: Ibf3d94a4d6f7abac19ed9740eeacfbcb1bdf1f4f
Signed-off-by: Jonathan Rajotte <>
Signed-off-by: Mathieu Desnoyers <>
7 weeks agoCleanup: tracepoint event: use different prefixes for provider and event descriptors
Mathieu Desnoyers [Mon, 4 Apr 2022 19:55:07 +0000 (15:55 -0400)] 
Cleanup: tracepoint event: use different prefixes for provider and event descriptors

Prefix the provider array of descriptor identifier with
"lttng_ust__provider_event_desc___" to distinguish it from the event
descriptor identifier.

This does not cause any conflict even when the event has the same name
as the provider because the provider is included in the event name. But
providing different prefixes is cleaner.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: If8b38d2765de61fd59558fe7c6223d1fdbb3349b

8 weeks agoFix: bytecode interpreter context_get_index() leaves byte order uninitialized
Mathieu Desnoyers [Wed, 30 Mar 2022 16:10:53 +0000 (12:10 -0400)] 
Fix: bytecode interpreter context_get_index() leaves byte order uninitialized

Observed Issue

When using the event notification capture feature to capture a context
field, e.g. '$ctx.cpu_id', the captured value is often observed in
reverse byte order.


Within the bytecode interpreter, context_get_index() leaves the "rev_bo"
field uninitialized in the top of stack.

This only affects the event notification capture bytecode because the
BYTECODE_OP_GET_SYMBOL bytecode instruction (as of lttng-tools 2.13)
is only generated for capture bytecode in lttng-tools. Therefore, only
capture bytecode targeting contexts are affected by this issue. The
reason why lttng-tools uses the "legacy" bytecode instruction to get
context (BYTECODE_OP_GET_CONTEXT_REF) for the filter bytecode is to
preserve backward compatibility of filtering when interacting with
applications linked against LTTng-UST 2.12.


Initialize the rev_bo field based on the context field type
reserve_byte_order field.

Known drawbacks


Signed-off-by: Mathieu Desnoyers <>
Change-Id: I74996d501cee3c269658d98dfc0d0050b74c5ddb

2 months agofix: __STDC_VERSION__ can be undefined in C++
Michael Jeanson [Thu, 17 Mar 2022 17:45:51 +0000 (13:45 -0400)] 
fix: __STDC_VERSION__ can be undefined in C++

Caught on SLES12 with g++ 4.8 when enabling '-Wundef'.

Change-Id: Ib027f224a4f0ef021beb1709d8a626db62fe6d9c
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
2 months agoFix: sample discarded events count before reserve
Mathieu Desnoyers [Wed, 9 Mar 2022 21:42:15 +0000 (16:42 -0500)] 
Fix: sample discarded events count before reserve

Sampling the discarded events count in the buffer_end callback is done
out of order, and may therefore include increments performed by following
events (in following packets) if the thread doing the end-of-packet
event write is preempted for a long time.

Sampling the event discarded counts before reserving space for the last
event in a packet, and keeping this as part of the private ring buffer
context, should fix this race.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ib59b634bbaefd2444751547d20a891c9dd93cd73

2 months agoFix: ring buffer event counter
Mathieu Desnoyers [Thu, 10 Mar 2022 14:58:37 +0000 (09:58 -0500)] 
Fix: ring buffer event counter

When compiling with -DLTTNG_RING_BUFFER_COUNT_EVENTS, the lttng-ust
libringbuffer can count events (with additional overhead). This is never
used or enabled by default. Fix this code so it compiles again when the
define is enabled.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I3aeeff7995d66a07316cc5c535b5271536a89636

2 months agoFix: concurrent exec(2) file descriptor leak
Mathieu Desnoyers [Wed, 9 Mar 2022 16:54:33 +0000 (11:54 -0500)] 
Fix: concurrent exec(2) file descriptor leak

If exec(2) is executed by the application concurrently with LTTng-UST
listener threads between the creation of a file descriptor with
socket(2), recvmsg(2), or pipe(2) and call to fcntl(3) FD_CLOEXEC, those
file descriptors will stay open after the exec, which is not intended.

As a consequence, shared memory files for ring buffers can stay present
on the file system for long-running traced processes.


- pipe2(2) O_CLOEXEC (supported since Linux 2.6.27, and by FreeBSD),
- socket(2) SOCK_CLOEXEC (supported since Linux 2.6.27, and by FreeBSD),
- recvmsg(2) MSG_CMSG_CLOEXEC (supported since Linux 2.6.23 and by FreeBSD),

rather than fcntl(2) FD_CLOEXEC to make sure the file descriptors are
closed on exec immediately upon their creation.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Id2167cf99d7cb8a8425fc0dc13745f023a504562

3 months agoAdd LOG4J2 domain to the Log4j 2.x agent
Michael Jeanson [Thu, 10 Feb 2022 15:25:54 +0000 (15:25 +0000)] 
Add LOG4J2 domain to the Log4j 2.x agent

This commit adds a new LOG4J2 domain with native Log4j 2.x loglevels in
addition to the existing LOG4J domain. Both domains can be used
individually or at the same time by instantiating one or more appenders.

For example, a single appender in Log4j 2.x native mode:

    <?xml version="1.0" encoding="UTF-8"?>
    <Configuration status="WARN">
        <Lttng name="LTTNG" domain="LOG4J2"/>
        <Root level="all">
          <AppenderRef ref="LTTNG"/>

Two appenders to enable both domains:

    <?xml version="1.0" encoding="UTF-8"?>
    <Configuration status="WARN">
        <Lttng name="LTTNG1" domain="LOG4J"/>
        <Lttng name="LTTNG2" domain="LOG4J2"/>
        <Root level="all">
          <AppenderRef ref="LTTNG1"/>
          <AppenderRef ref="LTTNG2"/>

Change-Id: I9a41e107d19d5a0efffe055edf0ca5211a7f6d6b
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
3 months agoAdd 'domain' parameter to the Log4j 2.x agent
Michael Jeanson [Thu, 10 Feb 2022 15:25:02 +0000 (15:25 +0000)] 
Add 'domain' parameter to the Log4j 2.x agent

The initial Log4j 2.x agent commit only implemented a compatibility mode
to be used with the existing LOG4J domain in lttng-tools.

In this mode the agent converts the new Log4j 2.x loglevel values to
their corresponding Log4j 1.x values in the same way the upstream
compatibility bridge does.

This is great when doing in-place migration using the upstream
compatibility bridge but doesn't cover the usecase of an application
that natively uses Log4j 2.x.

This commit adds a new mandatory 'domain' parameter to the Log4j2 agent
which currently only implements the 'LOG4J' compatibility domain in
preparation to adding a 'LOG4J2' domain.

The configuration for a single appender in Log4j 1.x compat mode will
now look like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <Configuration status="WARN">
        <Lttng name="LTTNG" domain="LOG4J"/>
        <Root level="all">
          <AppenderRef ref="LTTNG"/>

Change-Id: I7fd5f79ad58c77175714bd4198d8ff5db2e6b846
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
3 months agofix: Convert custom loglevels in Log4j 2.x agent
Michael Jeanson [Wed, 2 Feb 2022 19:04:50 +0000 (19:04 +0000)] 
fix: Convert custom loglevels in Log4j 2.x agent

The loglevel integer representation has changed between log4j 1.x and
2.x, we currently convert the standard loglevels but passthrough the
custom ones.

This can be problematic when using severity ranges as custom loglevels
won't be properly filtered.

Use the same strategy as the upstream Log4j 2.x compatibility layer by
converting the custom loglevels to their equivalent standard loglevel

Change-Id: I8cbd4706cb774e334380050cf0b407e19d7bc7c4
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
3 months agofix: coverity reported null returns in Log4j2 agent
Michael Jeanson [Fri, 28 Jan 2022 18:58:12 +0000 (18:58 +0000)] 
fix: coverity reported null returns in Log4j2 agent

According to the log4j javadoc, these methods should not return null but
since it's reported by Coverity, add the null checks.

*** CID 1469124:  Null pointer dereferences  (NULL_RETURNS)
194 in org.lttng.ust.agent.log4j2.LttngLogAppender.append(org.apache.logging.log4j.core.LogEvent)()

*** CID 1469123:  Null pointer dereferences  (NULL_RETURNS)
167 in org.lttng.ust.agent.log4j2.LttngLogAppender.append(org.apache.logging.log4j.core.LogEvent)()

Change-Id: Ib992b3cc6848492cfb6e7d8fec6ce3898d962db4
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
4 months agoFix: ustcomm: serialize variant_nestable type
Mathieu Desnoyers [Tue, 25 Jan 2022 02:08:35 +0000 (21:08 -0500)] 
Fix: ustcomm: serialize variant_nestable type

LTTng-UST 2.13 serializes the contents of the variant_nestable union
field, but keeps the "atype" as lttng_ust_ctl_atype_variant.

It happens to work by pure chance because the binary layout of the
variant_nestable and legacy.variant union fields are the same, except
for the alignment field of variant_nestable which is zeroed padding in
the legacy.variant. Therefore, as long as the variant_nestable has a
padding of 0, everything works out fine (which is currently the case).

But it's better to fix this discrepancy in case we ever plan to use a
nonzero variant alignment.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I96a3e1f6bfbe410ed61ea59313eb49b6c4f4b40d

4 months agoAdd a Log4j 2.x Java agent
Michael Jeanson [Thu, 6 Jan 2022 19:36:46 +0000 (14:36 -0500)] 
Add a Log4j 2.x Java agent

This adds a new agent to the LTTng-UST Java agents suite supporting the
Log4j 2.x logging backend.

This new agent can be enabled with 2 different configure options :

  1) Java agent with Log4j 2.x support:
  $ export CLASSPATH=/path/to/log4j-core.jar:/path/to/log4j-api.jar
  $ ./configure --enable-java-agent-log4j2

  2) Java agent with JUL + Log4j + Log4j2 support
  $ export CLASSPATH=/path/to/log4j-core.jar:/path/to/log4j-api.jar:/path/to/log4j-1.2.jar
  $ ./configure --enable-java-agent-all

The name of the new agent jar file is "lttng-ust-agent-log4j2.jar".
It will be installed in the arch-agnostic "$prefix/share/java" path
e.g: "/usr/share/java".

It uses the same jni library "" as the Log4j 1.x agent.

The agent was designed as a mostly drop-in replacement for applications
upgrading from Log4j 1.x to 2.x. It requires no modification to the
tracing configuration as it uses the same domain "-l / LOG4J" and the
loglevels integer representations are converted to the Log4j 1.x values
(excluding custom loglevels).

The recommended way to use this agent with Log4j 2.x is to add an
"Lttng" Appender with an arbiraty name and associate it with one or more
Logger using an AppenderRef.

For example, here is a basic log4j2 xml configuration that would send
all logging statements exlusively to an lttng appender:

    <?xml version="1.0" encoding="UTF-8"?>
    <Configuration status="WARN">
        <Lttng name="LTTNG"/>
        <Root level="all">
          <AppenderRef ref="LTTNG"/>

More examples can be found in the 'doc/examples' directory.

The implementation of the appender is based on this[1] great guide by
Keith D. Gregory which is so much more detailed than the official
documentation, my thanks to him.


Change-Id: I34593c9a4c3140c8839cef8b58cc85745fe9f47f
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
4 months agoFix: may be used uninitialized on powerpc
Michael Jeanson [Tue, 18 Jan 2022 19:14:33 +0000 (19:14 +0000)] 
Fix: may be used uninitialized on powerpc

Fix the following warning on powerpc :

    In file included from ../../src/common/counter/counter-internal.h:16,
                     from ../../src/common/counter/counter-api.h:16,
                     from counter-clients/percpu-64-modular.c:12:
    In function ‘__lttng_counter_add_percpu’,
        inlined from ‘lttng_counter_add’ at ../../src/common/counter/counter-api.h:265:10,
        inlined from ‘counter_add’ at counter-clients/percpu-64-modular.c:53:9:
    include/urcu/compiler.h:25:42: warning: ‘move_sum’ may be used uninitialized [-Wmaybe-uninitialized]
       25 | #define caa_unlikely(x) __builtin_expect(!!(x), 0)
          |                                          ^~~~~
    ../../src/common/counter/counter-api.h:244:13: note: in expansion of macro ‘caa_unlikely’
      244 |         if (caa_unlikely(move_sum))
          |             ^~~~~~~~~~~~
    In file included from counter-clients/percpu-64-modular.c:12:
    counter-clients/percpu-64-modular.c: In function ‘counter_add’:
    ../../src/common/counter/counter-api.h:237:17: note: ‘move_sum’ declared here
      237 |         int64_t move_sum;
          |                 ^~~~~~~~

Change-Id: I65dc61a567c0337735124a35f1af96697d416054
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
4 months agoProperly capture java variables at configure
Michael Jeanson [Thu, 20 Jan 2022 16:52:04 +0000 (16:52 +0000)] 
Properly capture java variables at configure

Some Java related variables aren't currently properly captured when
running for example:

    ./configure JAVACFLAGS="-g"

The JAVACFLAGS variable will be used during the configure phase but
won't be when running make afterwards.

This is due to the AX_JAVA_OPTIONS macro which adds non-standard
configure switches like '--with-javac-flags' which as a side-effect
inhibit the capture of the variable.

Remove this macro and use AC_ARG_VAR to capture these variables and
bring the Java support in line with C/C++.

Change-Id: I9159e34c1c30a10309200bfc8e0fd067000d14ce
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
4 months agoAdd basic Eclipse setup for log4j
Jonathan Rajotte [Tue, 18 Jan 2022 16:07:23 +0000 (11:07 -0500)] 
Add basic Eclipse setup for log4j

Change-Id: I2f4c6002b50b39b851f88ff46cb13046b5d363ba
Signed-off-by: Jonathan Rajotte <>
Signed-off-by: Mathieu Desnoyers <>
4 months agoFix: doc/examples/java-log4j: fix paths to directories
Mathieu Desnoyers [Tue, 18 Jan 2022 15:37:56 +0000 (10:37 -0500)] 
Fix: doc/examples/java-log4j: fix paths to directories

Since the directory hierarchy refactoring introduced in the 2.13 release
of lttng-ust, the paths in `run` are wrong, they are missing a `src`

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ibfcf8ac7f85049432f4788a5134e06eb5fe2434e

4 months agoFix: doc/examples/java-jul: fix paths to directories
Simon Marchi [Fri, 7 Jan 2022 16:31:58 +0000 (11:31 -0500)] 
Fix: doc/examples/java-jul: fix paths to directories

I tried to run this example, but got:

    $ ./run
    Error: Unable to initialize main class Hello
    Caused by: java.lang.NoClassDefFoundError: org/lttng/ust/agent/jul/LttngLogHandler

The paths in `run` are wrong, they are missing a `src` component.  Fix

Change-Id: I63f4532c5ec1d989f66b7061a154986692e2edf9
Signed-off-by: Simon Marchi <>
Signed-off-by: Mathieu Desnoyers <>
4 months agoCopyright ownership transfer
Mathieu Desnoyers [Fri, 14 Jan 2022 19:59:43 +0000 (14:59 -0500)] 
Copyright ownership transfer

Apply copyright ownership transfer from David Goulet and Julien Desfossez
to EfficiOS Inc.

Signed-off-by: Mathieu Desnoyers <>
Cc: David Goulet <>
Cc: Julien Desfossez <>
Signed-off-by: David Goulet <>
Signed-off-by: Julien Desfossez <>
Change-Id: Ibc6bb52296406e68466d44ae991a7ab70134dd76

5 months agoFix: ust-compiler: constructor/destructor build on g++ 4.8
Mathieu Desnoyers [Thu, 9 Dec 2021 21:07:15 +0000 (16:07 -0500)] 
Fix: ust-compiler: constructor/destructor build on g++ 4.8

g++ 4.8 build fails with:

15:16:07 ../../../../include/lttng/ust-compiler.h:104:31: error: can’t set ‘no_instrument_function’ attribute after definition
15:16:07   LTTNG_UST__TP_COMBINE_TOKENS(lttng_ust_constructor_destructor_,         \
15:16:07                                ^
15:16:07 ../../../../include/lttng/tracepoint.h:84:3: note: in definition of macro ‘LTTNG_UST___TP_COMBINE_TOKENS’
15:16:07    _tokena##_tokenb
15:16:07    ^
15:16:07 ../../../../include/lttng/ust-compiler.h:104:2: note: in expansion of macro ‘LTTNG_UST__TP_COMBINE_TOKENS’
15:16:07   LTTNG_UST__TP_COMBINE_TOKENS(lttng_ust_constructor_destructor_,         \
15:16:07   ^
15:16:07 ../../../../include/lttng/ust-tracepoint-event.h:1230:1: note: in expansion of macro ‘LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR’
15:16:07  ^
15:16:07 In file included from ../../../../include/lttng/tracepoint.h:25:0,
15:16:07                  from ust_tests_hello.h:13,
15:16:07                  from tp-cpp.cpp:8:
15:16:07 ../../../../include/lttng/ust-compiler.h:109:2: error: can’t set ‘no_instrument_function’ attribute after definition
15:16:07   ~LTTNG_UST__TP_COMBINE_TOKENS(lttng_ust_constructor_destructor_,        \
15:16:07   ^
15:16:07 ../../../../include/lttng/ust-tracepoint-event.h:1230:1: note: in expansion of macro ‘LTTNG_UST_DECLARE_CONSTRUCTOR_DESTRUCTOR’
15:16:07  ^

Fix this by moving the implementation of the constructor and destructor
outside of the class, thus applying the attribute to a forward

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I9e097d50dff7a8f9bef07b04ddad38bd6877f892

5 months agoust-compiler: constructor/destructor whitespaces layout and macro dependency
Mathieu Desnoyers [Thu, 9 Dec 2021 20:40:19 +0000 (15:40 -0500)] 
ust-compiler: constructor/destructor whitespaces layout and macro dependency

Introduce LTTNG_UST_COMPILER_COMBINE_TOKENS in lttng/ust-compiler.h to
eliminate a circular dependency from ust-compiler.h to
LTTNG_UST__TP_COMBINE_TOKENS (defined in tracepoint.h). Use it in

tabs rather than spaces.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I71ecac349a1425401df62eb600ee74f4f930da09

5 months agoFix: ust-cancelstate: include string.h for strerror
Mathieu Desnoyers [Thu, 9 Dec 2021 19:43:06 +0000 (14:43 -0500)] 
Fix: ust-cancelstate: include string.h for strerror

strerror() is provided by string.h, not error.h. Also error.h is not
present on FreeBSD, which causes the build to fail.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Id5e29df184c1f24659e15bc16c73da01fc819905

5 months agoFix: libnuma is prepended to LIBS
Jonathan Rajotte [Tue, 9 Nov 2021 15:43:53 +0000 (10:43 -0500)] 
Fix: libnuma is prepended to LIBS

The default behavior, for AC_CHECK_LIB when the `action-if-found` is NOT
defined, is to prepend the library to LIBS. [1]

If action-if-found is not specified, the default action prepends
-llibrary to LIBS and defines ‘HAVE_LIBlibrary’ (in all capitals).

It is important to note that the LIBS variable is used for ALL linking.

This is normally not a problem for most distribution since they force
the use of `--as-needed` at the toolchain level (gcc specs) (for example
debian [2]). One could also pass the `--as-needed` flag manually but
libtool reorganize flags in the case of shared object creation [3].

In our case, we always explicitly state the dependencies via the *_LIBADD
automake clause. We do not rely on the LIBS variable.

Simply force the define of HAVE_LIBNUMA to prevent the prepending to


Signed-off-by: Jonathan Rajotte <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I33221d14b96482ff71672458097423289f6b9fc2

5 months agofix: Allow disabling some abi compat tests
Michael Jeanson [Thu, 2 Dec 2021 21:11:21 +0000 (16:11 -0500)] 
fix: Allow disabling some abi compat tests

Allow disabling ABI compat tests that rely on a library using a symbol from
the global offset table even if it provides its own copy, which is the
default behavior on Linux.

This situation happens when using the '-Bsymbolic-functions' linker flag
which binds references to public symbols in a library to the definition
within the library, bypassing the global offset table.

To disable those tests when running the test suite, set the
UST_TESTS_LD_SYMBOLIC_FUNC environment variable to any value, for
example :


Change-Id: I1ed23d90bbe1b174ab7b4fccfb40b701b291c074
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
5 months agoFix: generate probe registration constructor as a C++ constuctor
Jérémie Galarneau [Mon, 6 Dec 2021 21:51:48 +0000 (16:51 -0500)] 
Fix: generate probe registration constructor as a C++ constuctor

Observed issue

Applications which transitively dlopen() a library which, in turn,
dlopen() providers crash when they are compiled with clang or

  Core was generated by `././myapp.exe'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x00007fa94f860bc2 in check_event_provider (probe_desc=<optimized out>) at lttng-probes.c:153
  153 if (!check_type_provider(field->type)) {
  [Current thread is 1 (Thread 0x7fa94fcbc740 (LWP 511754))]

  (gdb) bt
  #0  0x00007fa94f860bc2 in check_event_provider (probe_desc=<optimized out>) at lttng-probes.c:153
  #1  lttng_ust_probe_register (desc=0x7fa94fe9dc80 <lttng_ust__probe_desc___embedded_sys>)
      at lttng-probes.c:242
  #2  0x00007fa94fe9ba3c in lttng_ust__tracepoints__ptrs_destroy ()
      at /usr/include/lttng/tracepoint.h:590
  #3  0x00007fa94fedfe2e in call_init () from /lib64/
  #4  0x00007fa94fedff1c in _dl_init () from /lib64/
  #5  0x00007fa94fdf7d45 in _dl_catch_exception () from /usr/lib/
  #6  0x00007fa94fee420a in dl_open_worker () from /lib64/
  #7  0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/
  #8  0x00007fa94fee39bb in _dl_open () from /lib64/
  #9  0x00007fa94fe8d36c in ?? () from /usr/lib/
  #10 0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/
  #11 0x00007fa94fdf7db3 in _dl_catch_error () from /usr/lib/
  #12 0x00007fa94fe8db99 in ?? () from /usr/lib/
  #13 0x00007fa94fe8d3f8 in dlopen () from /usr/lib/
  #14 0x00007fa94fecc647 in mon_constructeur () at mylib.cpp:20
  #15 0x00007fa94fedfe2e in call_init () from /lib64/
  #16 0x00007fa94fedff1c in _dl_init () from /lib64/
  #17 0x00007fa94fdf7d45 in _dl_catch_exception () from /usr/lib/
  #18 0x00007fa94fee420a in dl_open_worker () from /lib64/
  #19 0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/
  #20 0x00007fa94fee39bb in _dl_open () from /lib64/
  #21 0x00007fa94fe8d36c in ?? () from /usr/lib/
  #22 0x00007fa94fdf7ce8 in _dl_catch_exception () from /usr/lib/
  #23 0x00007fa94fdf7db3 in _dl_catch_error () from /usr/lib/
  #24 0x00007fa94fe8db99 in ?? () from /usr/lib/
  #25 0x00007fa94fe8d3f8 in dlopen () from /usr/lib/
  #26 0x00005594f478c18c in main ()


Building tracepoint instrumentation as C++ using clang causes
compiler version detection problem addressed by another patch.

defined still results in the crash.

lttng_ust_event_field lttng_ust__event_fields__[...] structure is
initialized by dynamically-allocating field structures for the various

As the initialization can't be performed statically, it is performed at
run-time _after_ the execution of the library constructors has

Moreover, the generated initialization
function of the provider (lttng_ust__events_init__[...]) is declared as being a library
constructor. Hence, this causes it to run before the
tracepoint fields structures has a chance to be initialized.

This all results in a NULL pointer dereference during the validation of
the fields.


When building providers as C++, the initialization function is defined
as the constructor of a class. This class is, in turn, instantiated in
an anonymous namespace.

For the purposes of this patch, the use of an anonymous namespace is
equivalent to declaring the instance as 'static', but it is preferred in

Known drawbacks



A reproducer is available:

Problem initially reported on dotnet/runtime's issue tracker:

Relevant LTTng-UST issue:

Fixes: #1339
Change-Id: I51cfbe74729bd45e2613a30bc8de17e08ea8233d
Signed-off-by: Jérémie Galarneau <>
Signed-off-by: Mathieu Desnoyers <>
5 months agoFix: nestable pthread cancelstate
Mathieu Desnoyers [Thu, 9 Sep 2021 16:49:26 +0000 (12:49 -0400)] 
Fix: nestable pthread cancelstate

The pthread cancelstate disable performed to ensure threads are not
cancelled while holding mutexes which are used in library destructors
does not currently support that those mutexes may be nested. It
generates error messages when using the fork and fd helpers when running
with LTTNG_UST_DEBUG=1. The effect of this is that the pthread
cancelstate can be re-enabled too soon when the first unlock is
performed (in a nested lock scenario), thus allowing the thread to be
cancelled while still holding a lock, and causing a deadlock on
application exit.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ife8b1fee04c7d7c480e59bdfc158abdee771994c

5 months agoFix: abort on decrement_sem_count during concurrent tracing start and teardown
Jonathan Rajotte [Mon, 6 Dec 2021 14:20:58 +0000 (09:20 -0500)] 
Fix: abort on decrement_sem_count during concurrent tracing start and teardown

Observed issue

The following backtrace has been reported:

 #0  __GI_raise (sig=sig@entry=6)
     at /usr/src/debug/glibc/2.31/git/sysdeps/unix/sysv/linux/raise.c:50
 #1  0x0000007f90b3fdd4 in __GI_abort () at /usr/src/debug/glibc/2.31/git/stdlib/abort.c:79
 #2  0x0000007f90b4bf50 in __assert_fail_base (fmt=0x7f90c3da98 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
     assertion=assertion@entry=0x7f9112cb90 "uatomic_read(&sem_count) >= count",
     file=file@entry=0x7f9112cb30 "/usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c",
 line=line@entry=664, function=function@entry=0x7f911317e8 <__PRETTY_FUNCTION__.10404> "decrement_sem_count")
     at /usr/src/debug/glibc/2.31/git/assert/assert.c:92
 #3  0x0000007f90b4bfb4 in __GI___assert_fail (assertion=assertion@entry=0x7f9112cb90 "uatomic_read(&sem_count) >= count",
     file=file@entry=0x7f9112cb30 "/usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c",
 line=line@entry=664, function=function@entry=0x7f911317e8 <__PRETTY_FUNCTION__.10404> "decrement_sem_count")
     at /usr/src/debug/glibc/2.31/git/assert/assert.c:101
 #4  0x0000007f910e3830 in decrement_sem_count (count=<optimized out>)
     at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:664
 #5  0x0000007f910e5d28 in handle_pending_statedump (sock_info=0x7f9115c608 <global_apps>)
     at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:737
 #6  handle_message (lum=0x7f8dde46d8, sock=3, sock_info=0x7f9115c608 <global_apps>)
     at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:1410
 #7  ust_listener_thread (arg=0x7f9115c608 <global_apps>)
     at /usr/src/debug/lttng-ust/2_2.13.0-r0/lttng-ust-2.13.0/src/lib/lttng-ust/lttng-ust-comm.c:2055
 #8  0x0000007f90af73e0 in start_thread (arg=0x7fc27a82f6)
     at /usr/src/debug/glibc/2.31/git/nptl/pthread_create.c:477
 #9  0x0000007f90bead5c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

It turns out that the main thread is at that point iterating over the
libraries destructors:

Thread 3 (LWP 1983):
 #0  0x0000007f92a68a0c in _dl_fixup (l=0x7f9054e510, reloc_arg=432)
     at /usr/src/debug/glibc/2.31/git/elf/dl-runtime.c:69
 #1  0x0000007f92a6ea3c in _dl_runtime_resolve () at ../sysdeps/aarch64/dl-trampoline.S:100
 #2  0x0000007f905170f8 in __do_global_dtors_aux () from <....>/crash/work/rootfs/usr/lib/
 #3  0x0000007f92a697f8 in _dl_fini () at /usr/src/debug/glibc/2.31/git/elf/dl-fini.c:138
 #4  0x0000007f90b54864 in __run_exit_handlers (status=0, listp=0x7f90c65648 <__exit_funcs>,
     run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
     at /usr/src/debug/glibc/2.31/git/stdlib/exit.c:108
 #5  0x0000007f90b549f4 in __GI_exit (status=<optimized out>)
     at /usr/src/debug/glibc/2.31/git/stdlib/exit.c:139
 #6  0x0000000000404c98 in a_function_name (....) at main.c:152
 #7  0x0000000000404a98 in main (argc=3, argv=0x7fc27a8858, env=0x7fc27a8878) at main.c:97


An enable command is processed at the same time that the lttng-ust
destructor is run. At the end of the command handling,
`handle_pending_statedump` is called. Multiple variables from the
`sock_info` struct are checked outside the UST lock at that point.

lttng-ust-comm.c +1406:
    * Performed delayed statedump operations outside of the UST
    * lock. We need to take the dynamic loader lock before we take
    * the UST lock internally within handle_pending_statedump().


`statedump_pending` is set during the enable command
(`lttng_session_statedump`, lttng-events.c +631) in the same thread.

As for `registration_done` and `initial_statedump_done` they are invariant
from the registration of the app until `lttng_ust_cleanup` is called.
`cleanup_sock_info` called by `lttng_ust_cleanup`, itself called by
`lttng_ust_exit` resets the `registration_done` and
`initial_statedump_done` fields. Note that these operations are done
outside of the listener thread.

Note that by that point `lttng_ust_exit` expects all "getters" on
`sock_info` to fail while trying to acquire the UST lock due to
`lttng_ust_comm_should_quit` set to 1. Note that the listener threads
can still exist because we do not join them, we only execute
pthread_cancel which is async.

Clearly we are missing mutual exclusion provided by locking
when accessing `registration_done` and `initial_statedump_done`.


Here we can do better and simply not require any mutual exclusion based on locking.

`registration_done` and `initial_statedump_done` only need to be reset
to zero when we are not actually exiting (`lttng_ust_after_fork_child`).
In this case, no concurrent listener thread exists at that point
that could access those fields during the reset. Hence we can move the
reset to only the non-exiting code path and alleviate the current

Known drawbacks


Signed-off-by: Jonathan Rajotte <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I45ba3eaee20c49a3988837a87fa680ce0a6ed953

5 months agofix: allocating C++ compound literal on heap with Clang
Michael Jeanson [Mon, 6 Dec 2021 20:05:59 +0000 (15:05 -0500)] 
fix: allocating C++ compound literal on heap with Clang

Exclude Clang from the GCC version macro check for <= 4.8 since most
versions of Clang seem to identify themselves as GCC 4.2 which in this
case forces the allocation of C++ compound literals on the heap which
is only supported starting with Clang >= 6.0.

The macro was also broken for GCC <= 4.8 in C mode, add missing
parentheses around the 'or' statement to properly distinguish between C
and C++.

Also document the minimal supported version of Clang 4.0 to build C++
probe providers.

Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I62eea00381b7dc5958a09b13044ad9e7f7caf2ab

5 months agoCheck for C++11 when building C++ probe providers
Michael Jeanson [Wed, 8 Dec 2021 20:54:53 +0000 (15:54 -0500)] 
Check for C++11 when building C++ probe providers

The compiler used to build probe providers might differ from the one
used to build lttng-ust, make sure that when a probe provider is built
by a C++ compiler, it supports C++11.

Change-Id: I2a17e923316ff87c023d8e50c53efdbe35386a21
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
5 months agofix: liblttng-ust-fd async-signal-safe close()
Michael Jeanson [Tue, 9 Mar 2021 17:38:06 +0000 (12:38 -0500)] 
fix: liblttng-ust-fd async-signal-safe close()

"close(2)" is documented as async-signal-safe (see signal-safety(7)) and
as such our override function should also be. This means we shouldn't do
lazy initialization of the function pointer to the original libc close
symbol in the override function.

If we move the initialization of the function pointer in the library
constructor we risk breaking other constructors that may run before ours
and call close().

A compromise is to explicitly do the initialization in the constructor
but keep a lazy init scheme if close() is called before it is executed.

The dlsym call is now done only once, if it fails the wrappers will
return -1 and set errno to ENOSYS.

Change-Id: I05c66d2f5d51b2022c6803ca215340fb9c00f5a8
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
5 months agotracepoints: print debug message when is not found
Mathieu Desnoyers [Mon, 4 Oct 2021 20:44:57 +0000 (16:44 -0400)] 
tracepoints: print debug message when is not found

Rather than silently disable tracepoints when is
not found in the library search path, print a debug message when either
the compile unit including tracepoint.h has defined LTTNG_UST_DEBUG, or
when the LTTNG_UST_DEBUG environment variable is set.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I909f9b8dcd0cbc5faae3789931883f1941973207

5 months agoFix: static_assert unavailable with glibc < 2.16
Mathieu Desnoyers [Thu, 25 Nov 2021 21:02:29 +0000 (16:02 -0500)] 
Fix: static_assert unavailable with glibc < 2.16

gcc 4.8 introduces support for C11, and gcc 4.6 introduces support for
_Static_assert. Therefore, using _Static_assert when C11 is detected is
always OK.

However, using static_assert in C11 depends on glibc >= 2.16. Even
though the minimum version requirement for glibc is not documented in
the file, make a best effort to keep compatibility with older

Fixes: #1331
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I33b65b839ea5ecd0f710179a7ef6fb6f5fda2e17

5 months agoFix: combined tracing of lttng-ust 2.12/2.13 generates corrupted traces
Mathieu Desnoyers [Wed, 24 Nov 2021 19:13:28 +0000 (14:13 -0500)] 
Fix: combined tracing of lttng-ust 2.12/2.13 generates corrupted traces

Observed issue

When tracing applications linked against lttng-ust 2.12 and lttng-ust
2.13 in parallel with a lttng-tools 2.13 into the same per-uid buffers,
with the "procname" context enabled, babeltrace fails with "Event id NN
is outside range" when reading the trace:

[14:51:58.717006865] (+5.927872956) x lttng_ust_statedump:start: { cpu_id = 1 }, { procname = "sample-2.13-ust" }, { }
[error] Event id 41984 is outside range.
[error] Reading event failed.
Error printing trace.


Inspection of the trace reveals that the layout of the procname context
field changed from 17 bytes to 16 bytes between 2.12 and 2.13. This is
an issue when applications share a per-uid ring buffer, because context
fields are associated with channels, and need to have the same layout
across all processes tracing into a given channel.

The layout of the procname field described by the trace metadata is that
of the first application which happens to register that channel in the
session lifetime.

Therefore, the procname context field length is part of the LTTng-UST
ABI and cannot be changed without breaking the LTTng-UST ABI (bumping
between 2.12 and 2.13. Keeping compatibility for combined use by
different applications between lttng-ust 2.12 and 2.13 is a required
feature for this release, because lttng-ust 2.13 introduces a library
ABI break (soname bump).

An example scenario leading to this issue:

1) trace created for per-uid buffers,
2) add procname context
3) start tracing
4) Application [a] linked against lttng-ust 2.13 registers the channel to
   lttng-sessiond, sending its context descriptions with a 16-byte
   procname context field,
5) Application [b] linked against lttng-ust 2.12 registers the same channel
   to lttng-sessiond,
6) Application [b] traces an event with the procname context, followed
   by an event payload with a single "string" field.
7) A trace viewer will observe the procname context, followed by an
   extra null character, and thus mistakenly consider the event payload
   to be an empty string. Reading the next event header will fail
   because the string payload will be expected to contain an event ID.


Revert the procname context field size to 17 bytes to stay compatible
with lttng-ust 2.12.

In an abundance of caution, also revert the size of the
lttng_ust_statedump:procname "procname" field to 17, so there won't be
duplicated event IDs for this event when applications linked against
lttng-ust 2.12 and 2.13 are traced concurrently for the same user ID
in per-uid tracing.


This issue was introduced by commit 0db3d6ee9be ("port: fix
pthread_setname_np integration") within the 2.13 development cycle.

Known drawbacks

Applications currently running which are linked against a liblttng-ust
2.13 without this fix should be restarted after upgrading the library to
liblttng-ust 2.13 with this fix.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I206086df8b71463c248ca186343baaff5452762b

6 months agodoc/man: Document LTTNG_UST_ABORT_ON_CRITICAL variable
Michael Jeanson [Thu, 4 Nov 2021 16:14:59 +0000 (12:14 -0400)] 
doc/man: Document LTTNG_UST_ABORT_ON_CRITICAL variable

This new environment variable was added in 2.13 but only documented in
the README file, add it to the man page.

Change-Id: Ic7dbafe5cf7d8870a78d793134c789c5f24e80c8
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
6 months agofix: remove autoconf features default value in help message
Michael Jeanson [Thu, 11 Nov 2021 21:38:14 +0000 (16:38 -0500)] 
fix: remove autoconf features default value in help message

The default values of yes|no can be confusing combined with the
--enable / --disable switches of autoconf, remove them from the help

Change-Id: I9a85d6d759372d3932c9a8d302d42a468f2e6520
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
6 months agoAdd 'pid' to socket peercred on FreeBSD
Michael Jeanson [Mon, 19 Jul 2021 17:42:55 +0000 (13:42 -0400)] 
Add 'pid' to socket peercred on FreeBSD

The 'pid' of the socket peer was added to xucred in FreeBSD 12.

Lttng-tools doesn't yet have full support for FreeBSD but once it's
merged the baseline should be either FreeBSD 12 or 13 so we can get away
with no compat code.

Change-Id: I238baef7eedb3a909fb3804e6fd2cca4db84b21a
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
7 months agocleanup: spelling in java agent error message
Michael Jeanson [Thu, 29 Jul 2021 19:46:04 +0000 (15:46 -0400)] 
cleanup: spelling in java agent error message

Change-Id: I088f34e53809a0eb43c52212c1cbd308109fc9e9
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
7 months agocleanup: spelling fixes in comments
Michael Jeanson [Thu, 29 Jul 2021 19:44:14 +0000 (15:44 -0400)] 
cleanup: spelling fixes in comments

Change-Id: I79a51dcd9c4bffc227b94c2f9c1e83fde202c4fb
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
8 months agoFix: add extern "C" to two header files
Simon Marchi [Thu, 2 Sep 2021 02:30:02 +0000 (22:30 -0400)] 
Fix: add extern "C" to two header files

These are needed to build some lttng-tools binary as C++ programs.

Signed-off-by: Simon Marchi <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: Iba97d9cc52f86fd01cc24111c53a85340595e4c4

10 months agoDocumentation: clarify API backward compatibility comment
Mathieu Desnoyers [Fri, 28 May 2021 15:23:46 +0000 (11:23 -0400)] 
Documentation: clarify API backward compatibility comment

Considering that the ABI (soname major version) and API version can
evolve independently in the future, remove references to the soname
major version from the API compatibility documentation.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ic632c3d0f0940a689139a8e1d19dc5766382327e

11 months agodoc/man: only mention `-llttng-ust-common` in synopses (conditionally)
Philippe Proulx [Wed, 9 Jun 2021 19:39:25 +0000 (15:39 -0400)] 
doc/man: only mention `-llttng-ust-common` in synopses (conditionally)

LTTng-UST only requires that you link your application or tracepoint
provider package with `-llttng-ust-common` if you define
`_LGPL_SOURCE` before you include, directly or indirectly,

The `_LGPL_SOURCE` definition is specific to the EfficiOS/LTTng

Because defining `_LGPL_SOURCE` is not considered the typical scenario,
remove instructions to link with `-llttng-ust-common` throughout the
manual pages, except in synopses, to make such instructions more

Signed-off-by: Philippe Proulx <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I460a2f746d5e2904660a11b3151d0d01776361db

11 months agodoc/man: remove vtracef() and vtracelog() manual pages
Philippe Proulx [Wed, 9 Jun 2021 19:26:01 +0000 (15:26 -0400)] 
doc/man: remove vtracef() and vtracelog() manual pages

Following 2268c76f ("Remove vtracelog and vtracef from v0 compat API"),
this patch removes the manual pages of vtracef() and vtracelog() which
don't exist.

Signed-off-by: Philippe Proulx <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I1a07c74b330015ee74bb92235db2171066751503

11 months agoRemove vtracelog and vtracef from v0 compat API
Mathieu Desnoyers [Wed, 9 Jun 2021 15:38:08 +0000 (11:38 -0400)] 
Remove vtracelog and vtracef from v0 compat API

vtracelog and vtracef were introduced between lttng-ust 2.12 and 2.13
(not released yet). They are replaced by lttng_ust_vtracelog and
lttng_ust_vtracef in the v1 API, newly introduced in lttng-ust 2.13.

Therefore, there is no need to expose a v0 compat API for the vtracelog
and vtracef macros which were never officially part of any release
other than the 2.13 release candidates.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I96cfed7d6c211d24017bfd33cd8d8c5a7087d78f

11 months agoSet version to 2.14-pre
Michael Jeanson [Tue, 1 Jun 2021 18:56:33 +0000 (14:56 -0400)] 
Set version to 2.14-pre

Change-Id: I41c5a92bd6acc7d6ee88491c6146248d6e51b32d
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
11 months agoAdd serialized ABI definition files
Michael Jeanson [Wed, 3 Mar 2021 16:56:49 +0000 (11:56 -0500)] 
Add serialized ABI definition files

This commit contains the serialized ABI definitions for a typical build
of the lttng-ust librairies. This information is extracted using
libabigail (

The artefacts used to generate these were built with CFLAGS="-O0 -ggdb"
and all optional configure switches enabled.

You can compare the serialized ABI with a shared object to check for
changes. For example, here we compare an in-tree built version of with the serialized ABI of stable-2.13 :

  abidiff \
    extras/abi/2.13/x86_64-pc-linux-gnu/ \

Change-Id: Ie3b6fa78b156556bb9967bebab36c8e4f563bbe3
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
11 months agodoc/man: document LTTng-UST 2.13
Philippe Proulx [Tue, 25 May 2021 17:06:56 +0000 (13:06 -0400)] 
doc/man: document LTTng-UST 2.13

Significant changes:

* Prefix all macro/definition names with `LTTNG_UST_` or `lttng_ust_`
  where needed.

* Prefix all log level definitions with `LTTNG_UST_TRACEPOINT_LOGLEVEL`.

* lttng-ust(3):

  * Add "Compatibility with previous APIs" section to explain
    the new `LTTNG_UST_COMPAT_API_VERSION` definition.

  * Document the new tracepoint class provider name parameter of

    Update examples accordingly.

* Mention `liblttng-ust-common` where missing.

* tracef(3), vtracef(3), tracelog(3), and vtracelog(3) now indicate that
  the macros are part of version 0 of the LTTng-UST API, albeit still
  available, and point to lttng_ust_tracef(3), lttng_ust_vtracef(3),
  lttng_ust_tracelog(3), and lttng_ust_vtracelog(3).

* New lttng_ust_do_tracepoint(3), lttng_ust_tracepoint(3),
  and lttng_ust_tracepoint_enabled(3) manual pages which source

Signed-off-by: Philippe Proulx <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I07d6ace0d6f219c36d7c99a455726bbf4b0736a2

11 months agodoc: add -llttng-ust-common to linking cmd in manpages
Michael Jeanson [Tue, 27 Apr 2021 15:12:20 +0000 (11:12 -0400)] 
doc: add -llttng-ust-common to linking cmd in manpages

Change-Id: I82de93db32dd35b044810801ceab9dd2816d7fbd
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
11 months agodoc: xmlto output to stdout on a verbose build
Michael Jeanson [Tue, 27 Apr 2021 15:00:41 +0000 (11:00 -0400)] 
doc: xmlto output to stdout on a verbose build

When running 'make V=1' send the output of xmlto to stdout to help with
debugging command failures.

Change-Id: Ia974bb0ca9671129499b7966e8790a594ce034b2
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
12 months agoCleanup: remove useless lttng_ust_probe_supports_event_notifier
Mathieu Desnoyers [Thu, 27 May 2021 14:44:38 +0000 (10:44 -0400)] 
Cleanup: remove useless lttng_ust_probe_supports_event_notifier

LTTng-UST 2.13 bumps the accepted probe provider major version to 3,
therefore we can remove the lttng_ust_probe_supports_event_notifier
version check, which requires that the probe provider major version is
>= 2, because it is now useless.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Id31581d2728f1197788ce4e7a79c6c494c444b08

12 months agofix: disable some abi conflict tests on FreeBSD
Michael Jeanson [Mon, 17 May 2021 15:24:47 +0000 (11:24 -0400)] 
fix: disable some abi conflict tests on FreeBSD

On FreeBSD, symbol resolution when dlopening a shared object will always
favor symbols local to this shared object and thus our canary function will
never be called which breaks our abi conflict detection when abi1 is loaded

Disable the test cases with this scenario on FreeBSD as we have no way
to fix this at the moment.

Change-Id: Ic0451ce61e21f94ece55429b41bf76db3ad74b3a
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
12 months agoFix: handle leak in abi tests
Mathieu Desnoyers [Mon, 17 May 2021 12:40:17 +0000 (08:40 -0400)] 
Fix: handle leak in abi tests

Coverity finds that dlopen_ust leaks handles. Modify the code structure
to keep track of those handles in library descriptors so they are not

*** CID 1453155:    (RESOURCE_LEAK)
/tests/regression/abi0-conflict/app_ust_dlopen.c: 35 in dlopen_ust()
29                     printf("Error: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
30                     ret = EXIT_FAILURE;
31             } else {
32                     printf("Success: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
33             }
>>>     CID 1453155:    (RESOURCE_LEAK)
>>>     Variable "handle" going out of scope leaks the storage it points to.
35             return ret;
36     }
38     static
39     int dlopen_abi0(void)
40     {
/tests/regression/abi0-conflict/app_noust_dlopen.c: 31 in dlopen_ust()
25                     printf("Error: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
26                     ret = EXIT_FAILURE;
27             } else {
28                     printf("Success: dlopen of liblttng-ust shared library (%s).\n", lib_soname);
29             }
>>>     CID 1453155:    (RESOURCE_LEAK)
>>>     Variable "handle" going out of scope leaks the storage it points to.
31             return ret;
32     }
34     static
35     int dlopen_abi0(void)
36     {

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I967c2e8741c6d42c0c12e19fbadc81e1c91d1e0f

12 months agoFix: ustcomm: application name uses the '-ust'-suffixed thread name
Jérémie Galarneau [Fri, 14 May 2021 23:13:32 +0000 (19:13 -0400)] 
Fix: ustcomm: application name uses the '-ust'-suffixed thread name

During the 2.13 development cycle, the compatibility pthread_setname_np
compatibility layer was fixed (see 0db3d6ee). Unfortunately, this had a
detrimental effect.

Upon the registration of an application to the session daemon, its name
is sent as part of the 'struct lttng_ust_ctl_reg_msg' registration
message. The application name is sampled using lttng_pthread_getname_np
during the preparation of the message.

However, when the listener thread is launched, its name is changed
early-on to add a '-ust' suffix (see 01f0e40c). This suffixed name is
sampled and sent to the session daemon. Since, until recently, the
pthread_setname_np had no effect on most configurations, this had no

I noticed that this has a ripple-effect in the generation of some
path names. For instance, in per-pid mode, snapshots end-up with the
following hierarchy:

└── Mercury
    └── florence_jacques-20210514-162630
        └── snapshot-0-20210514-162726-1
            └── ust
                └── pid
                    └── hello-ust-332607-20210514-162538
                        ├── lol_0
                        ├── lol_1
                        ├── lol_10
                        ├── lol_11
                        ├── lol_2
                        ├── lol_3
                        ├── lol_4
                        ├── lol_5
                        ├── lol_6
                        ├── lol_7
                        ├── lol_8
                        ├── lol_9
                        └── metadata

Notice how the 'hello' application presents itself with the '-ust'
prefix. For such a short application name, it doesn't really matter
much beyond repeating the 'ust' unnecessarily. However, longer
application names quickly become less readable as we lose four of
the 16 precious allowed characters for a process name.

The procname sampled during the execution of the constructors is
reused. My understanding is that the procname stored in the sock_info
is already used for the 'procname' context.

The resulting hierarchy becomes:

└── Mercury
    └── sylvie_rouillard-20210514-193524
        └── snapshot-0-20210514-193553-0
            └── ust
                └── pid
                    └── hello-466576-20210514-193514
                        ├── lol_0
                        ├── lol_1
                        ├── lol_10
                        ├── lol_11
                        ├── lol_2
                        ├── lol_3
                        ├── lol_4
                        ├── lol_5
                        ├── lol_6
                        ├── lol_7
                        ├── lol_8
                        ├── lol_9
                        └── metadata

Signed-off-by: Jérémie Galarneau <>
Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ibd6f4763c96ea5fb680f55e5cc3d250baca175b0

12 months agoAdd abi0 conflict tests
Michael Jeanson [Tue, 27 Apr 2021 16:14:15 +0000 (12:14 -0400)] 
Add abi0 conflict tests

Add tests to make sure abi0 detection works properly in different
linking and dlopen scenarios.

Change-Id: I70927298163e5961e255250f7d8d6dd849d9d135
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
12 months agoDetect unsupported use of .so.0 and .so.1 libraries within same process
Mathieu Desnoyers [Tue, 27 Apr 2021 16:13:04 +0000 (12:13 -0400)] 
Detect unsupported use of .so.0 and .so.1 libraries within same process

Abort process if unsupported use of liblttng-ust and
liblttng-ust-tracepoint .so.0 vs .so.1 within the same process
is detected.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I2842ec43bf8840ddf88e0dd04bddb4c9e04e3a04

12 months agoAdd critical log level
Michael Jeanson [Thu, 13 May 2021 22:41:35 +0000 (18:41 -0400)] 
Add critical log level

Rename the unused BUG() macro to CRIT() to signify an error that can't
be recovered from. Add a new environment variable
LTTNG_UST_ABORT_ON_CRITICAL that when set will abort() on a critical log

Change-Id: Ib3384a66b7efa4004677b3c153f86cb97b06a091
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
12 months agoFix: shutdown communication socket on -EINVAL
Mathieu Desnoyers [Fri, 14 May 2021 19:24:27 +0000 (15:24 -0400)] 
Fix: shutdown communication socket on -EINVAL

Found by Coverity:
>>>     CID 1453150:  Control flow issues  (DEADCODE)
>>>     Execution cannot reach this statement: "(void)ustcomm_shutdown_unix...".

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I151e86167e8467ce3b602ddd0258284e0ef53eaa

12 months agoFix: lttng-ust control protocol handling of variable length command data
Mathieu Desnoyers [Thu, 13 May 2021 14:02:42 +0000 (10:02 -0400)] 
Fix: lttng-ust control protocol handling of variable length command data

The scheme for sending variable length data and file descriptors after
the command message causes irrecoverable "unknown commands" errors when
communicating with older versions of lttng-ust, because the receiver
(lttng-ust in applications) does not know that it needs to consume the
variable length data on the communication socket.

For the new commands introduced in the 2.13 cycle, we can change the
protocol on both ends (liblttng-ust-ctl and liblttng-ust) now to add
a reply to the fixed-size part of the command before sending the
variable length data and file descriptors.

For pre-existing commands sending variable length data and file
descriptors right after the fixed-size command, handle this
irrecoverable "unknown command" error by doing a socket shutdown from

Also document the protocol for each command sending variable length data
and file descriptors after the fixed-size command structure.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: If048c739dd37147ffb2a54715c2101177d2df4f7

12 months agoustcomm: implement shutdown API
Mathieu Desnoyers [Thu, 13 May 2021 13:55:49 +0000 (09:55 -0400)] 
ustcomm: implement shutdown API

Implement socket shutdown API to allow the ust-ctl library to shutdown
the communication socket when it cannot recover from errors which make
the sender and receiver out-of-sync.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: If896396d9104b21aee09981cac773996ed79aa4d

12 months agoFix: add missing fields in struct lttng_ust_abi_channel_config
Mathieu Desnoyers [Wed, 12 May 2021 19:48:27 +0000 (15:48 -0400)] 
Fix: add missing fields in struct lttng_ust_abi_channel_config

struct lttng_ust_abi_channel_config is meant to have the same binary
layout as struct lttng_channel in lttng-ust 2.12. Some fields were
removed (and should not be).

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I8c520b53e2c94244dcdb188fc3214e7cec72e876

12 months agoFix: liblttng-ust-ctl: keep using lttng-ust-sock-8 and lttng-ust-wait-8 filenames
Mathieu Desnoyers [Wed, 12 May 2021 18:02:32 +0000 (14:02 -0400)] 
Fix: liblttng-ust-ctl: keep using lttng-ust-sock-8 and lttng-ust-wait-8 filenames

commit 6a359b8a4006 ("Bump LTTNG_UST_ABI version from 8.1 to 9.0")
attempted to ensure that a session daemon linked against an old
lttng-ust-ctl (2.12) would not attempt to interact with newer

This was done by increasing the major ABI version number, but
a mean to allow session daemon to accept both major versions 8 and 9.

Unfortunately, changing LTTNG_UST_ABI_MAJOR_VERSION means the filenames
used for communication changed as well, meaning that applications linked
against older lttng-ust 2.12 cannot interact with lttng sessiond linked
against lttng-ust-ctl 2.13, which is unintended.

Therefore, go back to using the previous filenames: lttng-ust-sock-8,
and lttng-ust-wait-8 for communication.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ieeabc23c1d7c58eb1b6d4387c1e2b0f35b171bf3

12 months agoliblttng-ust-ctl: Implement SIGBUS handling
Mathieu Desnoyers [Thu, 8 Oct 2020 15:08:59 +0000 (11:08 -0400)] 
liblttng-ust-ctl: Implement SIGBUS handling

There is an issue with the security model of lib ring buffer (lttng-ust)
vs SIGBUS handling by consumer daemon. We do not handle SIGBUS in the
consumer daemon. An application using ftruncate on a ring buffer shm
could cause the consumer to be killed with SIGBUS.

Expose the relevant APIs to allow consumer daemon to handle SIGBUS.

It requires the user application (consumerd) to define the TLS sigbus
state with DEFINE_LTTNG_UST_SIGBUS_STATE(), and to invoke
lttng_ust_ctl_sigbus_handle() when a SIGBUS is received, passing the
address causing the SIGBUS (siginfo->si_addr) as parameter.

Internally, liblttng-ust-ctl uses sigsetjmp and siglongjmp to recover
from SIGBUS, and track all accesses to shared memory ranges within the

This modifies the API of liblttng-ust-ctl, and requires the user
application to define the TLS sigbus state with
DEFINE_LTTNG_UST_SIGBUS_STATE(). It therefore needs to be introduced in
locked-step between lttng-ust and lttng-tools.

It requires a major version bump of liblttng-ust-ctl soname.

Fixes: #1284
Signed-off-by: Mathieu Desnoyers <>
Change-Id: I7ade988e3e68a87930fbcee3e14e59c3fb66e755

12 months agoFix: Java application context: pass application context argument to callbacks
Mathieu Desnoyers [Tue, 11 May 2021 18:59:49 +0000 (14:59 -0400)] 
Fix: Java application context: pass application context argument to callbacks

The callbacks require the complete application context field names to
compare against the tables received from the TLS area.

We also need to free memory allocated by for the context event field and
context name in a destroy callback.

Therefore, allocate a data structure for each application context, and
use that data structure as private data. This allows callback to reach
the context name, and a destroy callback to free the allocated memory.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ia34fe00f5945fb58ef991f9d40dec36ac9ab322c

12 months agoFix: java application context segmentation fault
Mathieu Desnoyers [Tue, 11 May 2021 14:28:02 +0000 (10:28 -0400)] 
Fix: java application context segmentation fault

Type mismatch for application context private data causes segmentation
faults in the lttng-ust java testsuite.

This can be solved by using the private data provided by the application
context rather than struct lttng_ust_app_ctx, which is not needed

This also fixes a memory leak on context add error.

Those issues were introduced by the 2.13 development cycle refactorings.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I19c4e2d0ef6bcb7d4f9c2ffa43a9425661df05c1

12 months agoAdd api0 compile tests
Michael Jeanson [Thu, 29 Apr 2021 17:44:46 +0000 (13:44 -0400)] 
Add api0 compile tests

These compile tests will detect if we break the build of tracepoint
providers using the api0 of lttng-ust <= 2.12.

Change-Id: I208cfcbb624a799b3e32fc22bcbcfc03c547a466
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
12 months agoMove current compile tests to 'api1'
Michael Jeanson [Thu, 29 Apr 2021 16:03:02 +0000 (12:03 -0400)] 
Move current compile tests to 'api1'

Move the current compile tests to the 'api1' directory and build them

Change-Id: Ic46d549b5ec0735931bb2aa64115909fb2e25414
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
12 months agofix: namespacing of 'tp_rcu_read_lock'
Michael Jeanson [Thu, 29 Apr 2021 16:23:04 +0000 (12:23 -0400)] 
fix: namespacing of 'tp_rcu_read_lock'

Namespace a forgotten instance of 'tp_rcu_read_lock'.

Change-Id: I7572684c5c6de1bb7b7721e81a8a706c5f2d3f02
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
12 months agoValidate provider version for event enum field types
Mathieu Desnoyers [Wed, 5 May 2021 20:42:33 +0000 (16:42 -0400)] 
Validate provider version for event enum field types

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I77c17f45eb8e57dfa906ed061a4ab09bace9d248

12 months agoValidate provider version for event class
Mathieu Desnoyers [Wed, 5 May 2021 20:19:52 +0000 (16:19 -0400)] 
Validate provider version for event class

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I36db2da05933ea8b3ff1fbfcbdc7cc5efaa3d609

12 months agoAdd probe descriptor field to enum and event class
Mathieu Desnoyers [Wed, 5 May 2021 20:08:19 +0000 (16:08 -0400)] 
Add probe descriptor field to enum and event class

If future event instances can refer to event classes located in
different probe providers, the tracer needs to be able to query the
major/minor version of the probe provider containing the class.

Likewise for enumerations.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ifb39a52c70e14ce4d77c247d237d456257072b34

12 months agoRefactoring: tracepoint: allow explicit tracepoint instance provider name
Mathieu Desnoyers [Wed, 5 May 2021 19:04:38 +0000 (15:04 -0400)] 
Refactoring: tracepoint: allow explicit tracepoint instance provider name

Add a template_provider argument to LTTNG_UST_TRACEPOINT_EVENT_INSTANCE
to allow a tracepoint instance to refer to a tracepoint class from
another provider within the same compile unit.

Also introduce struct lttng_ust_tracepoint_class to clearly split the
event instance from the class, thus allowing the event instance to refer
to the class through a single symbol. This removes the need to rely on
LTTNG_UST__TP_ARRAY_SIZE() to calculate the size of the event field
array (part of the class) from within the event instance. This
refactoring opens the door to have event class and instance not only in
different providers, but also in providers emitted within different
compile units and shared objects in the future.

For instance, if a .c includes the following headers:

 #include "a.h"
 #include "b.h"

where a.h contains:

        LTTNG_UST_TP_ARGS(int, anint),
                lttng_ust_field_integer(int, intfield, anint)

and b.h contains:

        b, myeventinstance,
        LTTNG_UST_TP_ARGS(int, anint)

This is a localized API-breaking change introduced very early in the
2.13-rc cycle.

This changes the ABI exposed by the probe providers, so bump the probe
provider major version, and make newer lttng-ust reject old incompatible
major. We can do this because it is very early in the 2.13-rc cycle.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Icf25dc950e483719a26785cd17be9f3d113f7237

12 months agoFix: rename struct lttng_bytecode_runtime to struct lttng_ust_bytecode_runtime
Mathieu Desnoyers [Mon, 3 May 2021 14:23:00 +0000 (10:23 -0400)] 
Fix: rename struct lttng_bytecode_runtime to struct lttng_ust_bytecode_runtime

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I0a42d623af72bbc01eeb5e96c1974652fe7e3df2

12 months agoRemove unused ip field from struct lttng_ust_ring_buffer_ctx_private
Mathieu Desnoyers [Wed, 28 Apr 2021 18:19:12 +0000 (14:19 -0400)] 
Remove unused ip field from struct lttng_ust_ring_buffer_ctx_private

This field has been moved to struct lttng_ust_probe_ctx.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ibcbec8cbfef6461bfe0ca2891224f5d39e4fc7a5

13 months agoVersion 2.13.0-rc1 v2.13.0-rc1
Mathieu Desnoyers [Sat, 24 Apr 2021 01:14:30 +0000 (21:14 -0400)] 
Version 2.13.0-rc1

Signed-off-by: Mathieu Desnoyers <>
Change-Id: If2ddeb54443862b28696e2e746027c3473e04f8b

13 months agoSet the 2.13 release codename and description
Michael Jeanson [Fri, 23 Apr 2021 19:22:06 +0000 (15:22 -0400)] 
Set the 2.13 release codename and description

Change-Id: If25fb57fcd384f1b9868f1c8d4be2fbc6af71163
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agosequence type: use previous field for length if length_name is NULL
Mathieu Desnoyers [Mon, 12 Apr 2021 18:04:36 +0000 (14:04 -0400)] 
sequence type: use previous field for length if length_name is NULL

A common use-case for sequences is to use the field located immediately
prior to the sequence as sequence length.

The fact that the sequence type needs to explicitly contain its length
name ties the sequence type to where it is placed within the structure
fields, preventing re-use of the sequence type.

In order to reduce the memory footprint of the field descriptions and
allow re-use of common field types, special-case the NULL length_name to
use the field prior to the sequence as length.

This allows more efficient type descriptions without reducing the
overall flexibility of sequence layout.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I5f2ae22ecc4d872d56f9302751990452fc34cb15

13 months agotracepoint: Declare tracepoint module register/unregister API
Mathieu Desnoyers [Sat, 24 Apr 2021 00:05:40 +0000 (20:05 -0400)] 
tracepoint: Declare tracepoint module register/unregister API

The registration/unregistration API is part of the ABI, and used through
dlopen/dlsym, but its declaration is not exposed in the API.

Add the missing declarations.

Also remove useless "extern" on

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I0aecdf02c0dd604f960dc49ec4aa71613474c9b6

13 months agoconfigure: fix printing a description containing a comma
Michael Jeanson [Fri, 23 Apr 2021 19:39:58 +0000 (15:39 -0400)] 
configure: fix printing a description containing a comma

Change-Id: I66258d1f790193e3a3fa4c65d194822c09e49f0c
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoRename lttng_ust_tracepoint_(un)register_lib
Michael Jeanson [Fri, 23 Apr 2021 18:13:45 +0000 (14:13 -0400)] 
Rename lttng_ust_tracepoint_(un)register_lib

Change-Id: I15d84c682da4ce98ca872f36a765ab8db22c1dcc
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoRename lttng_ust_tracepoint_probe_(un)register
Michael Jeanson [Fri, 23 Apr 2021 18:12:20 +0000 (14:12 -0400)] 
Rename lttng_ust_tracepoint_probe_(un)register

Change-Id: Ic010cf596f1c89c41322e0cad2f0b044440cc187
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMove pkgconfig file to 'src/lib/'
Michael Jeanson [Fri, 23 Apr 2021 01:01:41 +0000 (21:01 -0400)] 
Move pkgconfig file to 'src/lib/'

Change-Id: I9e57ae0ddcf97466ea2ad5b335c0c9318c156daf
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMove the ringbuffer and counter clients to 'src/common/'
Michael Jeanson [Thu, 22 Apr 2021 22:36:47 +0000 (18:36 -0400)] 
Move the ringbuffer and counter clients to 'src/common/'

The clients are used by both liblttng-ust and liblttng-ust-ctl, now that
the clock and getcpu plugins on which they depend have been moved to
liblttng-ust-common, they can be extracted from liblttng-ust-ctl and
move to common convenience libraries.

Change-Id: I8384570007950ca18d00759790cb5264b7c3b528
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMove the getcpu plugin implementation to liblttn-ust-common
Michael Jeanson [Fri, 23 Apr 2021 00:39:28 +0000 (20:39 -0400)] 
Move the getcpu plugin implementation to liblttn-ust-common

The getcpu plugin is used by both liblttng-ust and liblttng-ust-ctl, move
it to liblttng-ust-common.

Change-Id: Ifdef881188e744ffd2c19670959612aaca8d73d9
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMove the clock plugin implementation to liblttng-ust-common
Michael Jeanson [Thu, 22 Apr 2021 18:07:20 +0000 (14:07 -0400)] 
Move the clock plugin implementation to liblttng-ust-common

The clock plugin is used by both liblttng-ust and liblttng-ust-ctl, move
it to liblttng-ust-common.

Change-Id: Ie2fd6947b0531cb10f5de2f5aaf42a1701a44458
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMake futex compat internal to liblttng-ust
Michael Jeanson [Thu, 22 Apr 2021 16:48:52 +0000 (12:48 -0400)] 
Make futex compat internal to liblttng-ust

This compat header originated in userspace RCU where it's used across
multiple shared objects hence the need to have the mutexes as public
weak symbols, in our case it's only used internally by liblttng-ust so
we can hide them.

If we end up using this compat header in another library in this project
we will have to use the same scheme, but in the meantime, don't expose
those symbols in the ABI.

Move the code to the liblttng-ust directory to make sure it's not used
by other libraries.

Change-Id: Ibfaef9448eeaf6247b42f71d6b6d8de234d79a3c
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMove dynamic-type to libcommon
Michael Jeanson [Thu, 22 Apr 2021 16:18:57 +0000 (12:18 -0400)] 
Move dynamic-type to libcommon

It is used by both liblttng-ust and liblttng-ust-ctl and contains no
shared state.

Change-Id: I51fc7a616d5e426a9286d873da29ffa661859f46
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMove lttng_ust_enum_get_from_desc to libcommon
Michael Jeanson [Thu, 22 Apr 2021 15:31:50 +0000 (11:31 -0400)] 
Move lttng_ust_enum_get_from_desc to libcommon

It is used by both liblttng-ust and liblttng-ust-ctl and contains no
shared state.

Change-Id: I8079e2c81cf72fe2075205608cf5e99aa07f6dfd
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoMove lttng_ust_strerror to liblttng-ust
Michael Jeanson [Thu, 22 Apr 2021 00:17:56 +0000 (20:17 -0400)] 
Move lttng_ust_strerror to liblttng-ust

Move the implementation of lttng_ust_strerror to liblttng-ust, it's part
of its public ABI and should not be copied in multiples libraries.

Change-Id: I825769d6c62b25e3e21b71abd18241998c6dde85
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoExpose a common alloc_tls for liblttng-ust-common
Michael Jeanson [Fri, 23 Apr 2021 18:06:31 +0000 (14:06 -0400)] 
Expose a common alloc_tls for liblttng-ust-common

Expose a common function to force the allocation of all TLS variables
owned by liblttng-ust-common, hide the fd-tracker behind it.

Change-Id: I6acfe7f85bce1e8939cd8e1d64ecb979525fa547
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoRename all 'fixup_tls' functions to 'alloc_tls'
Michael Jeanson [Fri, 23 Apr 2021 17:56:39 +0000 (13:56 -0400)] 
Rename all 'fixup_tls' functions to 'alloc_tls'

Use a term that makes it clearer we are forcing the allocation of lazy
allocated TLS variables.

Change-Id: I9bba052598ba9a62553043f91128d676b9393e71
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoHide symbols that shouldn't be part of the ABI
Michael Jeanson [Wed, 21 Apr 2021 23:19:16 +0000 (19:19 -0400)] 
Hide symbols that shouldn't be part of the ABI

Change-Id: I1d3304cb60dddbd8cdb7ec9fdef66326564a3b7c
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoHide internal tracepoint and providers data symbols
Mathieu Desnoyers [Fri, 23 Apr 2021 17:59:09 +0000 (13:59 -0400)] 
Hide internal tracepoint and providers data symbols

The tracepoint and providers definitions are always defined and used
within the same module, so there is no point in exporting those symbols.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I6730e1221cc15e5f3be63402828bb755322ca003

13 months agotracepoint: introduce macros to hide tracepoint/provider symbols
Mathieu Desnoyers [Fri, 23 Apr 2021 16:25:53 +0000 (12:25 -0400)] 
tracepoint: introduce macros to hide tracepoint/provider symbols

Introduce the following macros:

tracepoint module instrumentation.

with tracepoint provider.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I493c325b73c16044dcc117b48cc91df3b05f18b0

13 months agoNamespace liblttng-ust-ctl symbols
Michael Jeanson [Wed, 21 Apr 2021 22:31:54 +0000 (18:31 -0400)] 
Namespace liblttng-ust-ctl symbols

The ABI bump gives us the opportunity to namespace all public symbols
under the 'lttng_ust_' prefix. Rename all liblttng-ust-ctl symbols from
'ustctl_' to 'lttng_ust_ctl_'.

Change-Id: Ic2b9da019e7776b24b98824ae63d16b86c5a5742
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoPrefix public header include guards with LTTNG_UST_
Mathieu Desnoyers [Thu, 22 Apr 2021 16:57:39 +0000 (12:57 -0400)] 
Prefix public header include guards with LTTNG_UST_

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I00a82a300dfd405bddfd30418236d49160998562

13 months agofix: missing prefix LTTNG_UST_ for FLOAT_WORD_ORDER on FreeBSD
Michael Jeanson [Thu, 22 Apr 2021 15:38:36 +0000 (11:38 -0400)] 
fix: missing prefix LTTNG_UST_ for FLOAT_WORD_ORDER on FreeBSD

Change-Id: Ic9dec8c8c094c00e0066c4d8dfa499a3ec5d68fe
Signed-off-by: Michael Jeanson <>
Signed-off-by: Mathieu Desnoyers <>
13 months agoCleanup: probe function: use __ prefixed identifiers for local variables
Mathieu Desnoyers [Thu, 22 Apr 2021 15:24:41 +0000 (11:24 -0400)] 
Cleanup: probe function: use __ prefixed identifiers for local variables

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I28aab40777ac2221ede847bc63354170a8741125

13 months agoAPI refactoring: introduce probe context
Mathieu Desnoyers [Thu, 22 Apr 2021 12:46:18 +0000 (08:46 -0400)] 
API refactoring: introduce probe context

Introduce a "probe context" to allow passing the "ip" context from the
probe function to the get_value callback used by the bytecode
interpreter. This enables the "ip" context to be used from the filter
bytecode and from the capture bytecode.

Also fix signedness of the return type of the get_value context
callbacks for cases where the type is unsigned.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I2cb40a9b3bb34c42392bb663368e5af360554dbb

13 months agoFix: move compat macros for tracepoint probes to ust-tracepoint-event.h
Mathieu Desnoyers [Thu, 22 Apr 2021 15:11:36 +0000 (11:11 -0400)] 
Fix: move compat macros for tracepoint probes to ust-tracepoint-event.h

Do not pollute the compile units with API=0 defines for applications
instrumented with tracepoint.h but keeping the probe provider in a
separate compile unit.

Signed-off-by: Mathieu Desnoyers <>
Change-Id: Ic50c515448d628db33b1a7958853d9cd2034a81d

13 months agoRemove unused tp_list_for_each_entry_rcu
Mathieu Desnoyers [Thu, 22 Apr 2021 15:05:33 +0000 (11:05 -0400)] 
Remove unused tp_list_for_each_entry_rcu

Signed-off-by: Mathieu Desnoyers <>
Change-Id: I27925f8a3c23ab2bf18ad967df04afadae332801

This page took 0.090159 seconds and 4 git commands to generate.