Antoine Busque | 29 Nov 05:12 2015

[PATCH lttng-modules] Add prio field to process statedump

From: Antoine Busque <antoine.busque <at>>

This introduces a payload field named 'prio' for the process' priority
value to the lttng_statedump_process_state event. The prio field's
value corresponds to the value which would be provided by the prio
context for a given process. It is however computed directly, rather
than by calling the equivalent task_prio() function from the kernel.

Signed-off-by: Antoine Busque <abusque <at>>
 instrumentation/events/lttng-module/lttng-statedump.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/instrumentation/events/lttng-module/lttng-statedump.h b/instrumentation/events/lttng-module/lttng-statedump.h
index 916a6c5..fa1807f 100644
--- a/instrumentation/events/lttng-module/lttng-statedump.h
+++ b/instrumentation/events/lttng-module/lttng-statedump.h
 <at>  <at>  -7,6 +7,7  <at>  <at> 
 #include "../../../probes/lttng-tracepoint-event.h"
 #include <linux/nsproxy.h>
 #include <linux/pid_namespace.h>
+#include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/version.h>

 <at>  <at>  -63,6 +64,7  <at>  <at>  LTTNG_TRACEPOINT_EVENT(lttng_statedump_process_state,
 		ctf_array_text(char, name, p->comm, TASK_COMM_LEN)
+		ctf_integer(int, prio, p->prio - MAX_RT_PRIO)
(Continue reading)

Ronan CHAUVIN | 27 Nov 18:30 2015

lttng on aarch64 platform

Hello all,

I am trying to use lttng 2.7.0 on an aarch64 platform. When I create my 
session a trap is triggered which indicated that a unknow syscall (389) 
is called.

/ # lttng -vvv create mysession
DEBUG1 - 02:36:22.271714 [850/850]: Session daemon binary path: 
/usr/bin/lttng-sessiond (in launch_sessiond() at commands/create.c:668)
Spawning a session daemon
DEBUG1 - 02:36:24.275751 [850/850]: Session daemon terminated normally 
(exit status: 1) (in spawn_sessiond() at commands/create.c:606)
Error: Session daemon terminated with an error (exit status: 1)
Error: Problem occurred while launching session daemon 
Error: Command error
DEBUG1 - 02:36:24.275899 [850/850]: Clean exit (in clean_exit() at 

It seems that lttng-sessiond deamon is directly exited. Has anyone 
already tried on a 3.10 kernel and aarch64 platform?

Thanks in advance,


Embedded Software Engineer
ASIC & Video team
Parrot SA
(Continue reading)

Michael Jeanson | 27 Nov 22:24 2015

[PATCH lttng-tools] Tests: fix tracefile count when page_size is > 4k

Set the tracefile size according to the platform page_size and increase
the number of iterations to properly test the rotation.

Signed-off-by: Michael Jeanson <mjeanson <at>>
 tests/regression/tools/tracefile-limits/test_tracefile_count | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/regression/tools/tracefile-limits/test_tracefile_count b/tests/regression/tools/tracefile-limits/test_tracefile_count
index 4fe6ac3..6ada858 100755
--- a/tests/regression/tools/tracefile-limits/test_tracefile_count
+++ b/tests/regression/tools/tracefile-limits/test_tracefile_count
 <at>  <at>  -28,6 +28,7  <at>  <at>  STATS_BIN="$TESTDIR/utils/"


 source $TESTDIR/utils/

 <at>  <at>  -47,7 +48,7  <at>  <at>  function enable_lttng_channel_count_limit ()

 	$TESTDIR/../src/bin/lttng/$LTTNG_BIN enable-channel \
 	    -u $channel_name -s $sess_name \
-	    -C 4096 -W $tracefile_count_limit \
+	    -C $(($PAGE_SIZE*3)) -W $tracefile_count_limit \
 	    --overwrite >/dev/null 2>&1

 	ok $? "$test_name"
 <at>  <at>  -103,7 +104,7  <at>  <at>  function test_tracefile_count_limit ()
(Continue reading)

Julien Desfossez | 27 Nov 18:12 2015

[LTTNG-TOOLS PATCH] Fix: close indexes when rotating the trace files

The consumer needs to close the old index file when doing a file
rotation before opening a new one.
The relay does not have this problem (handled with refcounts).

Signed-off-by: Julien Desfossez <jdesfossez <at>>
 src/common/consumer/consumer.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/src/common/consumer/consumer.c b/src/common/consumer/consumer.c
index 2897fb8..5a90c29 100644
--- a/src/common/consumer/consumer.c
+++ b/src/common/consumer/consumer.c
 <at>  <at>  -1779,6 +1779,11  <at>  <at>  ssize_t lttng_consumer_on_read_subbuffer_splice(
 			outfd = stream->out_fd;

 			if (stream->index_fd >= 0) {
+				ret = close(stream->index_fd);
+				if (ret < 0) {
+					PERROR("Closing index");
+					goto end;
+				}
 				ret = index_create_file(stream->chan->pathname,
 						stream->name, stream->uid, stream->gid,

Zvi Vered | 27 Nov 05:20 2015

compile error in lttng-ust-2.4.4


I downloaded lttng-ust-2.4.4 extracted it and ran ./configure
Then I ran make.

I got the following error:

  CC       lttng-filter-specialize.lo
  CC       lttng-filter-interpreter.lo
  CC       lttng-ust-baddr.lo
In file included from ../include/lttng/ust-tracepoint-event.h:724,
                 from ../include/lttng/tracepoint-event.h:58,
                 from ust_baddr_statedump.h:56,
                 from lttng-ust-baddr.c:40:
././ust_baddr_statedump.h:40: error: weak declaration of
'__ref_loglevel___ust_baddr_statedump___soinfo' must be public
././ust_baddr_statedump.h:40: error:
'__ref_loglevel___ust_baddr_statedump___soinfo' defined both normally
and as an alias
././ust_baddr_statedump.h:40: error: weak declaration of
'__ref_model_emf_uri___ust_baddr_statedump___soinfo' must be public
././ust_baddr_statedump.h:40: error:
'__ref_model_emf_uri___ust_baddr_statedump___soinfo' defined both
normally and as an alias
make[2]: *** [lttng-ust-baddr.lo] Error 1
make[2]: Leaving directory
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/zvivered/GNU/lttng-ust/lttng-ust-2.4.4'
(Continue reading)

Zvi Vered | 27 Nov 04:20 2015

(no subject)


I downloaded lttng-tools-2.7.0 and tried to run ./configure.

I got the error message:

checking for xml2-config... /home/zvivered/GNU/libxml2/release/bin/xml2-config
checking for libxml - version >= 2.7.6... yes (version 2.7.7)
checking for uuid_generate in -luuid... no
checking for uuid_create in -lc... no
configure: error: Cannot find libuuid uuid_generate nor libc
uuid_create. Use LDFLAGS=-Ldir to specify their location.

I'm working with Centos 5.5 (32).
I downloaded libuuid-1.0.3.tar.gz from
It solved the .configure problem. Is this the right download place ?

Best regards,
Mathieu Desnoyers | 26 Nov 17:59 2015

[RELEASE] LTTng-UST 2.6.5 and 2.7.1 (Linux user-space tracer)

LTTng-UST, the Linux Trace Toolkit Next Generation Userspace Tracer,
is a low-overhead application tracer. The library "liblttng-ust" enables
tracing of applications and libraries.

Project website:
Download link:

Those releases are bugfix-only releases.

Changelog for 2.7.1
2015-11-26 lttng-ust 2.7.1
        * Fix: header size larger than 256 bytes
        * Remove stale tests/java-jul test
        * Fix: live timer calculation error
        * Fix python agent build/install/uninstall with DESTDIR specified
        * Fix: Don't (re)define STAP_PROBEV

Changelog for 2.6.5:
2015-11-26 lttng-ust 2.6.5
        * Fix: header size larger than 256 bytes
        * Remove stale tests/java-jul test
        * Fix: live timer calculation error
        * Fix: Don't (re)define STAP_PROBEV


Mathieu Desnoyers
EfficiOS Inc.
(Continue reading)

Luetkebohle Ingo (CR/AEA2 | 26 Nov 13:34 2015

faulty context for sched_stat_ tracepoints?



I noticed that the “procname” and “tid” *context* variables can differ from the “comm” and “tid” variables of the sched_stat_-tracepoints (e.g., for sched_stat_runtime).


For example, see the following two outputs:

[15:49:33.674072890] (+0.000029771) rng2070 sched_stat_sleep: { cpu_id = 4 }, { pid = 26974, procname = "amcl", tid = 26975 }, { comm = "lttng-sessiond", tid = 798, delay = 194122524 }

[15:49:33.722894563] (+0.000004851) rng2070 sched_stat_sleep: { cpu_id = 0 }, { pid = 0, procname = "swapper/0", tid = 0 }, { comm = "amcl", tid = 27078, delay = 10043658 }


In both cases, procname differs from comm.  I’ve looked at the kernel source code, and the “comm” variable is taken from task_struct.filename. Barring renames, this would be the correct one, so I’m assuming that the context is sometimes incorrect.


Now, for this particular case, I can take the correct variables from the tracepoint, but of course, this makes me worried that the context might also be wrong in other cases… Do you have any idea what could be going on here?


LTTng is Version 2.7.x+stable+bzr2948+pack17+201511192116~ubuntu14.04.1 and this is on a 3.19.0-33-generic kernel (btw, that’s not the default kernel for Ubuntu 14.04, but the LTS vivid backport kernel).


Mit freundlichen Grüßen / Best regards

Ingo Luetkebohle

Application Software (CR/AEA2)
Tel. +49(711)811-12248 | Fax +49(711)811-0 |
Ingo.Luetkebohle <at>

lttng-dev mailing list
lttng-dev <at>
Julien Desfossez | 25 Nov 18:54 2015

[MODULES PATCH] Bump version number for development branch

Signed-off-by: Julien Desfossez <jdesfossez <at>>
 lttng-tracer.h | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lttng-tracer.h b/lttng-tracer.h
index 020097f..a1972c5 100644
--- a/lttng-tracer.h
+++ b/lttng-tracer.h
 <at>  <at>  -40,13 +40,12  <at>  <at> 
 #include "lttng-events.h"


-#define LTTNG_VERSION_NAME		"Herbe à Détourne"
-	"Brewed with unrestrained amounts of Citra hop, the Herbe à Détourne is a fantastic New World Tripel
brewed by \"Dieu du Ciel!\". Aromas of mango, cantaloupe melon and passion fruit, combined with a
controlled bitter finish, unite in making this smooth golden-orange beer stand apart."

 #ifndef CHAR_BIT
 #define CHAR_BIT 8


lttng-dev mailing list
lttng-dev <at>
Jay Aurabind | 25 Nov 06:41 2015

Best practices to trace built in drivers

Hello everyone!

I am learning how to use lttng and I would like to get some
suggestions or best practices that you experienced hackers use to
trace kernel components.

Specifically I would like to know how I can easily trace built in
drivers which does its job well before the userspace has come up. For
example, I would like to trace the i915 driver, when configured to be
a built in module rather than  a module.

Please provide some suggestions on how to deal with this situation.



Thanks and Regards,
Aurabindo J
Mathieu Desnoyers | 24 Nov 13:15 2015

Re: Can TP_ARGS contain more than 10 elements?

----- On Nov 24, 2015, at 1:23 AM, < <at>> wrote:

   From man lttng-ust, I get "TP_ARGS macro contains the arguments passed for the tracepoint it is in the following format TP_ARGS(type1, name1, type2, name2, ... type10, name10) where there can be from zero to ten elements"

  Does anyone know is it possible to contain more than 10 elements in one TP_ARGS? If so ,how to do that ?

No, it is not possible. You may want to pass a structure instead.



Thanks in advance

lttng-dev mailing list
lttng-dev <at>

Mathieu Desnoyers
EfficiOS Inc.
lttng-dev mailing list
lttng-dev <at>