[lttng-dev] [RELEASE] LTTng-UST 2.8.2 (Linux user-space tracer)

[Mathieu Desnoyers]

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.

This is a bugfix release.

Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

Changelog:
2016-12-07 (National Earmuff Day) lttng-ust 2.8.2
* Fix: loglevel and model_emf_uri build fix
* Fix: loglevel and model_emf_uri with g++ compiled probes
* Fix: Out of tree build of liblttng-ust-java
* Fix: perform statedump before replying to sessiond
* Fix: honor send timeout on unix socket connect
* Fix: perform TLS fixup in all UST entry points from each thread
* Fix: remove unlock in getcpu
* Fix: perf counters ABI rdpmc detection
* Fix: perf counter context deadlock
* Fix: many-events registration/unregistration speed
* Fix: pre-fault TLS in ust-malloc instrumentation
* Fix: reset vtid cache before releasing urcu locks
* Fix: cleanup local_apps.allowed flag on lib cleanup
* Fix: Correctly handle invalid agent port file
* Fix: remove invalid free
* Fix: perf counters: sign-extend pmc register
* Fix: ctf_enum_value() does not work with g++
* Fix: allow non-LGPL modules to use tracepoints

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [RELEASE] LTTng-UST 2.7.5 (Linux user-space tracer) (EOL)

[Mathieu Desnoyers]

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.

Now that the 2.9 release of lttng-ust is out, lttng-ust 2.7.5 marks the end
of life of the stable-2.7 lttng-ust release branch. This version only adds
bugfixes.

Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

Changelog:
2016-12-07 (National Earmuff Day) lttng-ust 2.7.5
* Fix: loglevel and model_emf_uri build fix
* Fix: loglevel and model_emf_uri with g++ compiled probes
* Fix: Out of tree build of liblttng-ust-java
* Fix: perform statedump before replying to sessiond
* Fix: honor send timeout on unix socket connect
* Fix: perform TLS fixup in all UST entry points from each thread
* Fix: remove unlock in getcpu
* Fix: perf counters ABI rdpmc detection
* Fix: perf counter context deadlock
* Fix: many-events registration/unregistration speed
* Fix: pre-fault TLS in ust-malloc instrumentation
* Fix: reset vtid cache before releasing urcu locks
* Fix: cleanup local_apps.allowed flag on lib cleanup
* Fix: remove invalid free
* Fix: perf counters: sign-extend pmc register
* Fix: allow non-LGPL modules to use tracepoints
* Fix: strerror_r behavior is glibc specific
* Fix: don't generate 0-len array in tracepoint probes
* Fix: log4j example: set logger level to prevent unexpected level 
inheritance
* Fix: initialize RCU callbacks with mixed LGPL/non-LGPL objects
* Fix: incorrect structure layout with mixed LGPL/non-LGPL objects
* Fix: don't call __builtin_return_address(0) on 32-bit powerpc
* Fix: tracepoint header: declare tracepoint_dlopen_ptr
* Fix: update debug message about weak-hidden symbols
* Fix: tracepoint-rcu header: use tracepoint_dlopen_ptr
* Fix: work-around gcc optimisation oddness on 32-bit powerpc
-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [PATCH lttng-modules] Fix: asoc instrumentation for RHEL 7.3

[Mathieu Desnoyers]

Merged into master, 2.9, 2.8, thanks!

Mathieu

- On Dec 7, 2016, at 2:17 PM, Michael Jeanson mjean...@efficios.com wrote:

> Signed-off-by: Michael Jeanson 
> ---
> instrumentation/events/lttng-module/asoc.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/instrumentation/events/lttng-module/asoc.h
> b/instrumentation/events/lttng-module/asoc.h
> index 09e1fe2..25136ec 100644
> --- a/instrumentation/events/lttng-module/asoc.h
> +++ b/instrumentation/events/lttng-module/asoc.h
> @@ -21,7 +21,8 @@ struct snd_soc_card;
> struct snd_soc_dapm_widget;
> #endif
> 
> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0))
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0) \
> + || LTTNG_RHEL_KERNEL_RANGE(3,10,0,514,0,0, 3,11,0,0,0,0))
> #define CODEC_NAME_FIELD component.name
> #define CODEC_ID_FIELD component.id
> #else
> --
> 2.7.4

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [RELEASE EOL] LTTng-modules 2.7 branch end of life

[Mathieu Desnoyers]

Hi,

With the release of lttng-modules 2.9.0, the stable-2.7 branch
is reaching its end of life with lttng-modules 2.7.7. It will
therefore not be maintained anymore. lttng-modules 2.7.7 is the
last release of that stable branch.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [PATCH lttng-tools] Fix: Add missing pthread.h include

[Thomas Petazzoni]

Hello,

On Mon,  5 Dec 2016 15:39:26 -0500, Michael Jeanson wrote:
> Some libc like musl and uClibc requires explicit includes of pthread.h
> 
> Signed-off-by: Michael Jeanson 

Tested-by: Thomas Petazzoni 

This is indeed needed to fix the build on musl, I've integrated your
patch in Buildroot for the time being.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH lttng-modules] Fix: asoc instrumentation for RHEL 7.3

[Michael Jeanson]

Signed-off-by: Michael Jeanson 
---
 instrumentation/events/lttng-module/asoc.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/instrumentation/events/lttng-module/asoc.h 
b/instrumentation/events/lttng-module/asoc.h
index 09e1fe2..25136ec 100644
--- a/instrumentation/events/lttng-module/asoc.h
+++ b/instrumentation/events/lttng-module/asoc.h
@@ -21,7 +21,8 @@ struct snd_soc_card;
 struct snd_soc_dapm_widget;
 #endif
 
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0))
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0) \
+   || LTTNG_RHEL_KERNEL_RANGE(3,10,0,514,0,0, 3,11,0,0,0,0))
 #define CODEC_NAME_FIELD component.name
 #define CODEC_ID_FIELD component.id
 #else
-- 
2.7.4

___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [PATCH lttng-modules 1/2] Add SUSE Linux Enterprise kernel version tests

[Mathieu Desnoyers]

Merged into master, stable-2.8, stable-2.9, thanks!

Mathieu

- On Dec 7, 2016, at 11:09 AM, Michael Jeanson mjean...@efficios.com wrote:

> Signed-off-by: Michael Jeanson 
> ---
> Makefile.ABI.workarounds |  6 ++
> abi-sle-version.sh   | 42 ++
> lttng-kernel-version.h   | 19 +++
> 3 files changed, 67 insertions(+)
> create mode 100755 abi-sle-version.sh
> 
> diff --git a/Makefile.ABI.workarounds b/Makefile.ABI.workarounds
> index 470bdef..c3717f8 100644
> --- a/Makefile.ABI.workarounds
> +++ b/Makefile.ABI.workarounds
> @@ -16,6 +16,12 @@ ifneq ($(RHEL_API_VERSION), 0)
>   ccflags-y += -DRHEL_API_VERSION=$(RHEL_API_VERSION)
> endif
> 
> +SLE_API_VERSION:=$(shell $(TOP_LTTNG_MODULES_DIR)/abi-sle-version.sh 
> $(CURDIR))
> +
> +ifneq ($(SLE_API_VERSION), 0)
> +  ccflags-y += -DSLE_API_VERSION=$(SLE_API_VERSION)
> +endif
> +
> RT_PATCH_VERSION:=$(shell $(TOP_LTTNG_MODULES_DIR)/rt-patch-version.sh
> $(CURDIR))
> 
> ifneq ($(RT_PATCH_VERSION), 0)
> diff --git a/abi-sle-version.sh b/abi-sle-version.sh
> new file mode 100755
> index 000..0bd65b1
> --- /dev/null
> +++ b/abi-sle-version.sh
> @@ -0,0 +1,42 @@
> +#!/bin/sh
> +
> +# First argument is the path to the kernel headers.
> +KPATH=$1
> +
> +if [ ! -f "${KPATH}/include/generated/autoconf.h" ]; then
> + echo 0
> + exit 0
> +fi
> +
> +# Check if we are building against a Suse kernel
> +SUSE_KERNEL="$(sed -rn 's/^#define CONFIG_SUSE_KERNEL (.*)/\1/p'
> "${KPATH}/include/generated/autoconf.h")"
> +
> +if [ "$SUSE_KERNEL" != "1" ]; then
> + echo 0
> + exit 0
> +fi
> +
> +
> +if [ ! -f "${KPATH}/include/generated/utsrelease.h" ]; then
> + echo 0
> + exit 0
> +fi
> +
> +SLE_RELEASE="$(sed -rn 's/^#define UTS_RELEASE "(.*)-([0-9\.]+)-(.*)"/\2/p'
> "${KPATH}/include/generated/utsrelease.h")"
> +
> +SLE_RELEASE_MAJOR="$(echo "${SLE_RELEASE}" | sed -rn 
> 's/^([0-9]+)(.*)$/\1/p')"
> +SLE_RELEASE_MINOR="$(echo "${SLE_RELEASE}" | sed -rn
> 's/^([0-9]+)\.([0-9]+)(.*)$/\2/p')"
> +SLE_RELEASE_PATCH="$(echo "${SLE_RELEASE}" | sed -rn
> 's/^([0-9]+)\.([0-9]+)\.([0-9]+)(.*)$/\3/p')"
> +
> +# Minor and patch versions can be omitted
> +if [ "x$SLE_RELEASE_MINOR" = "x" ]; then
> + SLE_RELEASE_MINOR=0
> +fi
> +if [ "x$SLE_RELEASE_PATCH" = "x" ]; then
> + SLE_RELEASE_PATCH=0
> +fi
> +
> +# Combine all update numbers into one
> +SLE_API_VERSION="$((SLE_RELEASE_MAJOR * 1 + SLE_RELEASE_MINOR * 100 +
> SLE_RELEASE_PATCH))"
> +
> +echo ${SLE_API_VERSION}
> diff --git a/lttng-kernel-version.h b/lttng-kernel-version.h
> index d9a5f13..387aa0a 100644
> --- a/lttng-kernel-version.h
> +++ b/lttng-kernel-version.h
> @@ -96,6 +96,25 @@
>   LTTNG_RHEL_VERSION_CODE < \
>   LTTNG_RHEL_KERNEL_VERSION(a_high, b_high, c_high, d_high, 
> e_high, f_high))
> 
> +/* SUSE Linux enterprise */
> +
> +#define LTTNG_SLE_KERNEL_VERSION(a, b, c, d, e, f) \
> + (a) << 16) + ((b) << 8) + (c)) * 1000ULL) + ((d) * 1) + 
> ((e) *
> 100) + (f))
> +
> +#ifdef SLE_API_VERSION
> +#define LTTNG_SLE_VERSION_CODE \
> + ((LINUX_VERSION_CODE * 1000ULL) + SLE_API_VERSION)
> +#else
> +#define LTTNG_SLE_VERSION_CODE   0
> +#endif
> +
> +#define LTTNG_SLE_KERNEL_RANGE(a_low, b_low, c_low, d_low, e_low, f_low, \
> + a_high, b_high, c_high, d_high, e_high, f_high) \
> + (LTTNG_SLE_VERSION_CODE >= \
> + LTTNG_SLE_KERNEL_VERSION(a_low, b_low, c_low, d_low, e_low, 
> f_low) && \
> + LTTNG_SLE_VERSION_CODE < \
> + LTTNG_SLE_KERNEL_VERSION(a_high, b_high, c_high, d_high, 
> e_high, f_high))
> +
> /* RT patch */
> 
> #define LTTNG_RT_KERNEL_VERSION(a, b, c, d) \
> --
> 2.7.4

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Tracing a sequence of events through an application

[Julien Desfossez]

Hi,

> All,
> I'm wondering if this is something anyone has ever done before:
> We have a financial trading application for which we'd like to trace the 
> timing of a sequence of related events with low impact.  For example, tracing 
> a market data feed packet from its reception on the NIC, to its processing in 
> the Market Data portion of the code, and on & on via other layers of the 
> application until it finally reaches the Order Execution portion of the code 
> where it sends out an Order on the stock exchange.  We're wondering if 
> there's a proven reference for using LTTng-UST to enable session tracing 
> which would link related activities in this way, as opposed to just providing 
> aggregate timestamps at various tracepoints within our code.
> Has something like this ever been done before using LTTng-UST? If so, is 
> there a reference available?

For this use-case, you will probably be interested in the "period"
mechanism of lttng-analyses [1]. It gives you a way to express
relationships between events (how to link the beginning and the end of a
period), and have nested periods as well.

When you have written the periods definition, it gives you statistics,
logs and frequency distributions, based on the duration and number of
periods encountered. It also outputs the same statistics and frequency
distribution for each period in relationship with its parent(s), and
will very soon support grouping these results based on the payload (for
example: latency frequency distribution of a particular request when
fieldX = 42).

If you want a quick example, you can have a look at [2].

The limitation of this feature, is that all sub-periods need to be fully
nested within their parents, so your instrumentation needs to be in the
form of "begin A, begin B, end B, end A" where you have a way to link
"begin B" with "begin A" (compared to "state A -> state B"). It works
for both cases, but the first one provides much more context information
since you can link the periods together. So it's not exactly for
sequences of events, but the advantage of working with periods is that
it gives you a lot of automatic analyses and the end.

This feature is currently only in the master branch of lttng-analyses,
but we expect a release by the end of the year, so now is a good time to
start playing with it. After that, we will do blog posts to illustrate
more all that can be done with it. This is a very powerful feature, but
is not necessarily easy to grasp, so take the time to play with it.
Basically, if you can manually follow a period from a trace, you can
express it with this feature.

Otherwise, I know TraceCompass provides a way to define a state machine
to follow sequences of events, but I'm not that familiar with it,
someone else on this ML will be able to give more details.

For your use-case of tracing from the time the packet arrives on the NIC
and follow the request up to user-space, we have developed a tracker for
this problem in the latency-tracker [3]. It only works "online", so it's
not a post-processing solution, but it can be used to detect latencies
at run-time and trigger the capture of tracing snapshots to investigate
further. As far as I know, it is the only solution that can compute the
delay from an interrupt to user-space at run-time, and with a little
help from user-space, it can continue following the processing in
user-space. We did a presentation with Mathieu this year at LinuxCon,
you can watch it here [4]. This project is also still in development in
the master branch, but if you are interested in more details, let me
know.

We would like to have the same analysis in our offline analyses in
lttng-analyses, but haven't had the time/funding for that yet.

I hope this helps, let us know if you have more questions and if it
solves the problem.

Thanks,

Julien

[1] https://github.com/lttng/lttng-analyses#period-options
[2] http://imgur.com/a/bZCgR
[3] https://github.com/efficios/latency-tracker
[4] https://www.youtube.com/watch?v=fTgD7sKoa_g
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH lttng-modules 2/2] Fix: SCSI instrumentation for SLES12 SP2

[Michael Jeanson]

Signed-off-by: Michael Jeanson 
---
 instrumentation/events/lttng-module/scsi.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/instrumentation/events/lttng-module/scsi.h 
b/instrumentation/events/lttng-module/scsi.h
index 02e3353..adc7491 100644
--- a/instrumentation/events/lttng-module/scsi.h
+++ b/instrumentation/events/lttng-module/scsi.h
@@ -15,7 +15,8 @@
 
 #define scsi_opcode_name(opcode)   { opcode, #opcode }
 
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0))
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0) \
+   || LTTNG_SLE_KERNEL_RANGE(4,4,9,36,0,0, 4,5,0,0,0,0))
 
 #define show_opcode_name(val)  \
__print_symbolic(val,   \
-- 
2.7.4

___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH lttng-modules 1/2] Add SUSE Linux Enterprise kernel version tests

[Michael Jeanson]

Signed-off-by: Michael Jeanson 
---
 Makefile.ABI.workarounds |  6 ++
 abi-sle-version.sh   | 42 ++
 lttng-kernel-version.h   | 19 +++
 3 files changed, 67 insertions(+)
 create mode 100755 abi-sle-version.sh

diff --git a/Makefile.ABI.workarounds b/Makefile.ABI.workarounds
index 470bdef..c3717f8 100644
--- a/Makefile.ABI.workarounds
+++ b/Makefile.ABI.workarounds
@@ -16,6 +16,12 @@ ifneq ($(RHEL_API_VERSION), 0)
   ccflags-y += -DRHEL_API_VERSION=$(RHEL_API_VERSION)
 endif
 
+SLE_API_VERSION:=$(shell $(TOP_LTTNG_MODULES_DIR)/abi-sle-version.sh $(CURDIR))
+
+ifneq ($(SLE_API_VERSION), 0)
+  ccflags-y += -DSLE_API_VERSION=$(SLE_API_VERSION)
+endif
+
 RT_PATCH_VERSION:=$(shell $(TOP_LTTNG_MODULES_DIR)/rt-patch-version.sh 
$(CURDIR))
 
 ifneq ($(RT_PATCH_VERSION), 0)
diff --git a/abi-sle-version.sh b/abi-sle-version.sh
new file mode 100755
index 000..0bd65b1
--- /dev/null
+++ b/abi-sle-version.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+
+# First argument is the path to the kernel headers.
+KPATH=$1
+
+if [ ! -f "${KPATH}/include/generated/autoconf.h" ]; then
+   echo 0
+   exit 0
+fi
+
+# Check if we are building against a Suse kernel
+SUSE_KERNEL="$(sed -rn 's/^#define CONFIG_SUSE_KERNEL (.*)/\1/p' 
"${KPATH}/include/generated/autoconf.h")"
+
+if [ "$SUSE_KERNEL" != "1" ]; then
+   echo 0
+   exit 0
+fi
+
+
+if [ ! -f "${KPATH}/include/generated/utsrelease.h" ]; then
+   echo 0
+   exit 0
+fi
+
+SLE_RELEASE="$(sed -rn 's/^#define UTS_RELEASE "(.*)-([0-9\.]+)-(.*)"/\2/p' 
"${KPATH}/include/generated/utsrelease.h")"
+
+SLE_RELEASE_MAJOR="$(echo "${SLE_RELEASE}" | sed -rn 's/^([0-9]+)(.*)$/\1/p')"
+SLE_RELEASE_MINOR="$(echo "${SLE_RELEASE}" | sed -rn 
's/^([0-9]+)\.([0-9]+)(.*)$/\2/p')"
+SLE_RELEASE_PATCH="$(echo "${SLE_RELEASE}" | sed -rn 
's/^([0-9]+)\.([0-9]+)\.([0-9]+)(.*)$/\3/p')"
+
+# Minor and patch versions can be omitted
+if [ "x$SLE_RELEASE_MINOR" = "x" ]; then
+   SLE_RELEASE_MINOR=0
+fi
+if [ "x$SLE_RELEASE_PATCH" = "x" ]; then
+   SLE_RELEASE_PATCH=0
+fi
+
+# Combine all update numbers into one
+SLE_API_VERSION="$((SLE_RELEASE_MAJOR * 1 + SLE_RELEASE_MINOR * 100 + 
SLE_RELEASE_PATCH))"
+
+echo ${SLE_API_VERSION}
diff --git a/lttng-kernel-version.h b/lttng-kernel-version.h
index d9a5f13..387aa0a 100644
--- a/lttng-kernel-version.h
+++ b/lttng-kernel-version.h
@@ -96,6 +96,25 @@
LTTNG_RHEL_VERSION_CODE < \
LTTNG_RHEL_KERNEL_VERSION(a_high, b_high, c_high, d_high, 
e_high, f_high))
 
+/* SUSE Linux enterprise */
+
+#define LTTNG_SLE_KERNEL_VERSION(a, b, c, d, e, f) \
+   (a) << 16) + ((b) << 8) + (c)) * 1000ULL) + ((d) * 1) + 
((e) * 100) + (f))
+
+#ifdef SLE_API_VERSION
+#define LTTNG_SLE_VERSION_CODE \
+   ((LINUX_VERSION_CODE * 1000ULL) + SLE_API_VERSION)
+#else
+#define LTTNG_SLE_VERSION_CODE 0
+#endif
+
+#define LTTNG_SLE_KERNEL_RANGE(a_low, b_low, c_low, d_low, e_low, f_low, \
+   a_high, b_high, c_high, d_high, e_high, f_high) \
+   (LTTNG_SLE_VERSION_CODE >= \
+   LTTNG_SLE_KERNEL_VERSION(a_low, b_low, c_low, d_low, e_low, 
f_low) && \
+   LTTNG_SLE_VERSION_CODE < \
+   LTTNG_SLE_KERNEL_VERSION(a_high, b_high, c_high, d_high, 
e_high, f_high))
+
 /* RT patch */
 
 #define LTTNG_RT_KERNEL_VERSION(a, b, c, d) \
-- 
2.7.4

___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] Snapshot gives no events after calling it more then the number sub-buffers in the channel

[Anders Wallin]

Hi,

Taking a number of snapshots always showed the events in the buffer, before
the
commit de3fb857f034c208c135a10a3cdec2dfe43fbda6

Fix: ust-consumer: flush empty packets on snapshot channel

Snapshot operation on a non-stopped stream should use a "final" flush to
ensure empty packets are flushed, so we gather timestamps at the moment
where the snapshot is taken. This is important for streams that have a
low amount of activity, which might be on an empty packet when the
snapshot is triggered.

After this the number of snapshots that can be taken and getting events is
equal to number of sub-buffers!?
I think this i BUG!

The following test script shows the problem!
-
#!/bin/sh

TRACEAPP="/usr/lib/lttng-tools/ptest/tests/utils/testapp/gen-ust-events/gen-ust-events
1"
TRACEPATH=$HOME/lttng-snapshots
SESSION=tracetest
CHANNEL=tracechannel

# cleanup
lttng destroy $SESSION
rm -rf $TRACEPATH
sleep 1

lttng create $SESSION --snapshot -U file://$TRACEPATH
lttng enable-channel $CHANNEL -u --subbuf-size 4k --num-subbuf 2
lttng enable-event -a -u -c $CHANNEL -s $SESSION
lttng start $SESSION
lttng --version
#lttng list $SESSION

$TRACEAPP
sleep 1

for i in $(seq 1 5); do
  lttng snapshot record --session $SESSION --name $i-something
  sleep 1
  echo ""
  echo " $i print events"
  babeltrace $TRACEPATH/$i-something* | head -1
done


BEFOR the patch the output is like this (I have removed some lines to make
it easier to read);
--
Session tracetest created.
Default snapshot output set to: file:///root/lttng-snapshots
Snapshot mode set. Every channel enabled for that session will be set in
overwrite mode and mmap output.
UST channel tracechannel enabled for session tracetest
All UST events are enabled in channel tracechannel
Tracing started for session tracetest
lttng (LTTng Trace Control) 2.7.2

--- create some user events ---
Snapshot recorded successfully for session tracetest

 1 print events
[15:02:11.886716015] (+?.?) axxiaarm lttng_ust_statedump:start: {
cpu_id = 9 }, { }

Snapshot recorded successfully for session tracetest
 2 print events
[15:02:11.886716015] (+?.?) axxiaarm lttng_ust_statedump:start: {
cpu_id = 9 }, { }

Snapshot recorded successfully for session tracetest
 3 print events
[15:02:11.886716015] (+?.?) axxiaarm lttng_ust_statedump:start: {
cpu_id = 9 }, { }

Snapshot recorded successfully for session tracetest
 4 print events
[15:02:11.886716015] (+?.?) axxiaarm lttng_ust_statedump:start: {
cpu_id = 9 }, { }

Snapshot recorded successfully for session tracetest
 5 print events
[15:02:11.886716015] (+?.?) axxiaarm lttng_ust_statedump:start: {
cpu_id = 9 }, { }


AFTER the patch the output is like this (I have removed some lines to make
it easier to read);
--
Session tracetest created.
Default snapshot output set to: file:///root/lttng-snapshots
Snapshot mode set. Every channel enabled for that session will be set in
overwrite mode and mmap output.
UST channel tracechannel enabled for session tracetest
All UST events are enabled in channel tracechannel
Tracing started for session tracetest
lttng (LTTng Trace Control) 2.7.5

--- create some user events ---
Snapshot recorded successfully for session tracetest

 1 print events
[15:02:11.886716015] (+?.?) axxiaarm lttng_ust_statedump:start: {
cpu_id = 9 }, { }

Snapshot recorded successfully for session tracetest
 2 print events
[15:02:11.886716015] (+?.?) axxiaarm lttng_ust_statedump:start: {
cpu_id = 9 }, { }

Snapshot recorded successfully for session tracetest
 3 print events

Snapshot recorded successfully for session tracetest
 4 print events

Snapshot recorded successfully for session tracetest
 5 print events


Tested on 2.7.5 and 2.8.2 with the same result

Regards
Anders Wallin
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev