Re: [lttng-dev] [lttng-tools] Removal of root_regression tests

[Jonathan Rajotte-Julien via lttng-dev]

Hi Marcel,

- Original Message -
> From: "Marcel Hamer via lttng-dev" 
> To: "lttng-dev" 
> Sent: Monday, 13 June, 2022 07:49:39
> Subject: [lttng-dev] [lttng-tools] Removal of root_regression tests

> Hello,
> 
> Since version v2.12.9 of lttng-tools the root_regression file has been emptied
> to make the tests part of the 'make check' sequence instead.
> 
> We were always actively using that test file as part of our regression 
> testing.
> In our case we are working in a cross-compilation environment, where the 
> run.sh
> script was used on target for testing and as such not at compile time. It is 
> not
> easy to run a make check sequence on a target.

I would suggest that you take a look at how OpenEmbedded does it with ptest 
AFAIK it match your requirements:

https://github.com/openembedded/openembedded-core/blob/c7e2901eacf3dcbd0c5bb91d2cc1d467b4a9aaf7/meta/recipes-kernel/lttng/lttng-tools_2.13.7.bb#L75

> 
> It is now also a bit unclear which tests actually require root access and 
> which
> tests do not. I understood this was the reason the file was called
> 'root_regression'?

Yes when the tests suites primarily used `prove` via run.sh.

We have been slowly moving away from it for a good time and now mostly use the 
Automake test harness as much as possible.

The worse that will happen if you run a test that required root as a non-root 
user is that `skip` tap output will be emitted.

> 
> Some questions that get raised because of this:
> 
> - Is there now an alternative way to run regressions on target in case of a
>  cross-compilation environment?

AFAIU, this is out of scope of the lttng project. Still, I would recommend that 
you see how yocto/oe do it with ptest.

> - Would there be a possibility to fill the 'root_regression' file again and
>  possibly revert this change?

Feel free to do it out-of-tree. I doubt that we are the only project that 
WindRiver handles that uses
the automake test harness and that do not provide a easy way to run on-target 
for cross-compilation testing.

A quick grep with "isroot" should get you 95% there.

> - How are tests now identified that require root access?

All tests that require root access test for it at runtime

Something along:

regression/tools/streaming/test_high_throughput_limits:

 if [ "$(id -u)" == "0" ]; then
isroot=1
 else
 isroot=0
 fi

 skip $isroot "Root access is needed to set bandwidth limits. Skipping all 
tests." $NUM_TESTS ||
 {
 ...
Tests are done here.
 }

Cheers
___
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: cleanup stream on snapshot failure

[Jonathan Rajotte-Julien via lttng-dev]

Hi Marcel,

This is exactly the kind of reproducer we are looking for.

Thanks for providing it. I'll try it out and check if we need anything more in 
that patch.

Cheers

- Original Message -
> From: "Marcel Hamer" 
> To: "jonathan rajotte-julien" 
> Cc: "lttng-dev" 
> Sent: Tuesday, May 31, 2022 7:28:55 AM
> Subject: Re: [lttng-dev] [PATCH lttng-tools] Fix: cleanup stream on snapshot 
> failure

> Hello Jonathan,
> 
> On Mon, May 30, 2022 at 11:27:55AM -0400, Jonathan Rajotte-Julien wrote:
>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>> 
>> Hi Marcel,
>> 
>> Thanks for sending this patch.
>> 
>> Looks sensible to me, still do you have a reproducer for it? I went back to 
>> bug
>> 1352 and even with https://bugs.lttng.org/attachments/546 was unable to force
>> the assert failure.
> 
> I can only reproduce it when running lttng-consumerd in a debugger
> environment, in my case gdb. My reproduction scenario is:
> 
> 1. Setting a breakpoint on snapshot_channel() inside
>   src/common/ust-consumer/ust-consumer.c
> 2. When the breakpoint hits, remove the the complete lttng directory
>   containing the session data.
> 3. Continue the lttng_consumerd process from gdb.
> 4. In that case you see a negative return value -1 from
>   consumer_stream_create_output_files() inside snapshot_channel().
> 5. Take another snapshot and you will see lttng_consumerd crash because
>   of the assert(!stream->trace_chunk); inside snapshot_channel(). This
>   last action does not require any breakpoint intervention.
> 
> The scenario seems to be very timing sensitive to reproduce. I do not
> have a clear command sequence to achieve the same error.
> 
> The proposed patch prevents lttng_consumerd from crashing in step 5.
> 
> Kind regards,
> 
> Marcel
> 
>> 
>> Cheers
>> 
>> - Original Message -
>> > From: "Marcel Hamer via lttng-dev" 
>> > To: "lttng-dev" 
>> > Sent: Monday, 30 May, 2022 10:10:21
>> > Subject: [lttng-dev] [PATCH lttng-tools] Fix: cleanup stream on snapshot 
>> > failure
>> 
>> > When a channel snapshot creation fails the stream should be cleaned up
>> > properly. If the stream is not closed and cleaned properly on a failure,
>> > the next time a snapshot is created an assert is triggered for:
>> >
>> >   assert(!stream->trace_chunk);
>> >
>> > inside the snapshot_channel function. Since the stream->trace_chunk was
>> > not reset to NULL. The reset to NULL happens inside the
>> > consumer_stream_close function.
>> >
>> > Fixes #1352
>> >
>> > Signed-off-by: Marcel Hamer 
>> > ---
>> > src/common/ust-consumer/ust-consumer.c | 10 +-
>> > 1 file changed, 5 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/src/common/ust-consumer/ust-consumer.c
>> > b/src/common/ust-consumer/ust-consumer.c
>> > index f176ca40a..f43216829 100644
>> > --- a/src/common/ust-consumer/ust-consumer.c
>> > +++ b/src/common/ust-consumer/ust-consumer.c
>> > @@ -1147,13 +1147,13 @@ static int snapshot_channel(struct
>> > lttng_consumer_channel *channel,
>> >   if (use_relayd) {
>> >   ret = consumer_send_relayd_stream(stream, path);
>> >   if (ret < 0) {
>> > - goto error_unlock;
>> > + goto error_close_stream;
>> >   }
>> >   } else {
>> >   ret = consumer_stream_create_output_files(stream,
>> >   false);
>> >   if (ret < 0) {
>> > - goto error_unlock;
>> > + goto error_close_stream;
>> >   }
>> >   DBG("UST consumer snapshot stream (%" PRIu64 ")",
>> >   stream->key);
>> > @@ -1170,19 +1170,19 @@ static int snapshot_channel(struct
>> > lttng_consumer_channel *channel,
>> >   ret = lttng_ustconsumer_take_snapshot(stream);
>> >   if (ret < 0) {
>> >   ERR("Taking UST snapshot");
>> > - goto error_unlock;
>> > + goto error_close_stream;
>> >   }
>> >
>> >   ret = lttng_ustconsume

Re: [lttng-dev] [PATCH lttng-tools] Fix: cleanup stream on snapshot failure

[Jonathan Rajotte-Julien via lttng-dev]

Hi Marcel,

Thanks for sending this patch.

Looks sensible to me, still do you have a reproducer for it? I went back to bug 
1352 and even with https://bugs.lttng.org/attachments/546 was unable to force 
the assert failure.

Cheers

- Original Message -
> From: "Marcel Hamer via lttng-dev" 
> To: "lttng-dev" 
> Sent: Monday, 30 May, 2022 10:10:21
> Subject: [lttng-dev] [PATCH lttng-tools] Fix: cleanup stream on snapshot 
> failure

> When a channel snapshot creation fails the stream should be cleaned up
> properly. If the stream is not closed and cleaned properly on a failure,
> the next time a snapshot is created an assert is triggered for:
> 
>   assert(!stream->trace_chunk);
> 
> inside the snapshot_channel function. Since the stream->trace_chunk was
> not reset to NULL. The reset to NULL happens inside the
> consumer_stream_close function.
> 
> Fixes #1352
> 
> Signed-off-by: Marcel Hamer 
> ---
> src/common/ust-consumer/ust-consumer.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/src/common/ust-consumer/ust-consumer.c
> b/src/common/ust-consumer/ust-consumer.c
> index f176ca40a..f43216829 100644
> --- a/src/common/ust-consumer/ust-consumer.c
> +++ b/src/common/ust-consumer/ust-consumer.c
> @@ -1147,13 +1147,13 @@ static int snapshot_channel(struct
> lttng_consumer_channel *channel,
>   if (use_relayd) {
>   ret = consumer_send_relayd_stream(stream, path);
>   if (ret < 0) {
> - goto error_unlock;
> + goto error_close_stream;
>   }
>   } else {
>   ret = consumer_stream_create_output_files(stream,
>   false);
>   if (ret < 0) {
> - goto error_unlock;
> + goto error_close_stream;
>   }
>   DBG("UST consumer snapshot stream (%" PRIu64 ")",
>   stream->key);
> @@ -1170,19 +1170,19 @@ static int snapshot_channel(struct
> lttng_consumer_channel *channel,
>   ret = lttng_ustconsumer_take_snapshot(stream);
>   if (ret < 0) {
>   ERR("Taking UST snapshot");
> - goto error_unlock;
> + goto error_close_stream;
>   }
> 
>   ret = lttng_ustconsumer_get_produced_snapshot(stream, 
> _pos);
>   if (ret < 0) {
>   ERR("Produced UST snapshot position");
> - goto error_unlock;
> + goto error_close_stream;
>   }
> 
>   ret = lttng_ustconsumer_get_consumed_snapshot(stream, 
> _pos);
>   if (ret < 0) {
>   ERR("Consumerd UST snapshot position");
> - goto error_unlock;
> + goto error_close_stream;
>   }
> 
>   /*
> --
> 2.25.1
> 
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] how to create a issue about userspace rcu

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

You should have access to https://bugs.lttng.org/projects/urcu/issues/new when
you are logged in.

If not ping me in private and we will fix this. But afaik permissions looks good
for the urcu project.

Cheers

On Fri, Mar 25, 2022 at 11:15:02AM +0800, yaowenbin via lttng-dev wrote:
> Hello, I open the urcu webpage:
> https://bugs.lttng.org/projects/urcu.
> But I can not find where to create a issue. I just only can read the issues.
> How to create one.
> Thanks.
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

Re: [lttng-dev] In lttng-live mode, if the printing speed cannot keep up with the generation speed of the parsed ctf data, where will the data be stored?

[Jonathan Rajotte-Julien via lttng-dev]

On Wed, Mar 09, 2022 at 01:26:42AM +0800, 熊毓华 wrote:
> If for some reason (for example, here my socket send function in print_message
> is blocked and the Babeltrace2 may be suspended), the speed of the reader
> (babeltrace2) cannot keep up with the speed of the
> producer(lttng/lttng-consumerd), can the size of this buffer("lttng-relayd" )
> be set? How much data can it store？

Unless you are using --tracefile-size and --tracefile-count (man 
lttng-enable-channel), the limit here is
the backing filesystem of the host running lttng-relayd.

I suggest that you have a look at the overall architecture of lttng before going
further [1].

[1] https://lttng.org/docs/v2.13/#doc-plumbing

Cheers

> 
> Looking forward to your reply！
> 
> thx
> 
> Yuhua
> 
> 
> 
> 
> -原始邮件-
> 发件人:"Jonathan Rajotte-Julien" 
> 发送时间:2022-03-09 00:39:01 (星期三)
> 收件人: "熊毓华" 
> 抄送: lttng-dev , "Mathieu Desnoyers" 
> , yc...@northwestern.edu
> 主题: Re: In lttng-live mode, if the printing speed cannot keep up with the 
> generation speed of the parsed ctf data, where will the data be stored?
> 
> 
> Hi
> 
> 
> I wonder if my socket recv function is blocked on the other end, causing the 
> socket send function to block in print_message function in babeltrace2;or 
> when printing to the console, the printing speed can't keep up with the 
> parsed CTF data generation speed and the print buffer is also full.
> 
> In this case, how will Babeltrace2 handle the parsed CTF data that has not 
> been sent yet, store them in a buffer, a queue or just discard them? Or would 
> the blocking directly cause LTTng to discard the original CTF data at the 
> ring buffer before LTTng Consumer daemon?
> 
> 
> 
> Not sure I understand your setup but when using lttng-live, you are 
> effectively reading from the data that lttng-relayd is collecting, piece by 
> piece.
> The producing side is not affected by the speed at which the reader 
> (babeltrace2) consume data from lttng-relayd using the lttng-live protocol.
> There might be some corner case here and there but for most base usage of the 
> "live" feature reader (babeltrace2) and producer(lttng/lttng-consumerd)
> are "decoupled". You can consider the "lttng-relayd" (and the trace on the 
> filesystem) as the "buffer" here.

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

Re: [lttng-dev] In lttng-live mode, if the printing speed cannot keep up with the generation speed of the parsed ctf data, where will the data be stored?

[Jonathan Rajotte-Julien via lttng-dev]

Hi 

> I wonder if my socket recv function is blocked on the other end, causing the
> socket send function to block in print_message function in babeltrace2;or when
> printing to the console, the printing speed can't keep up with the parsed CTF
> data generation speed and the print buffer is also full.

> In this case, how will Babeltrace2 handle the parsed CTF data that has not 
> been
> sent yet, store them in a buffer, a queue or just discard them? Or would the
> blocking directly cause LTTng to discard the original CTF data at the ring
> buffer before LTTng Consumer daemon?
Not sure I understand your setup but when using lttng-live, you are effectively 
reading from the data that lttng-relayd is collecting, piece by piece. 
The producing side is not affected by the speed at which the reader 
(babeltrace2) consume data from lttng-relayd using the lttng-live protocol. 
There might be some corner case here and there but for most base usage of the 
"live" feature reader (babeltrace2) and producer(lttng/lttng-consumerd) 
are "decoupled". You can consider the "lttng-relayd" (and the trace on the 
filesystem) as the "buffer" here. 
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] 回复： 回复： shm leak in traced application?

[Jonathan Rajotte-Julien via lttng-dev]

Hi zhenyu.ren,

Please open a bug on our bug tracker and provide a reproducer against the latest
stable version (2.13.x).

https://bugs.lttng.org/

Please follow the guidelines: https://bugs.lttng.org/#Bug-reporting-guidelines

Cheers

On Fri, Feb 25, 2022 at 12:47:34PM +0800, zhenyu.ren via lttng-dev wrote:
> Hi, lttng-dev team 
>When lttng-sessiond exits, the ust applications should call 
> lttng_ust_objd_table_owner_cleanup() and clean up all shm resource(unmap and 
> close). Howerver I do find that the ust applications keep opening "all" of 
> the shm fds("/dev/shm/ust-shm-consumer-81132 (deleted)") and do NOT free shm.
>If we run lttng-sessiond again, ust applications can get a new piece of 
> shm and a new list of shm fds so double shm usages. Then if we kill 
> lttng-sessiond, what the mostlikely happened is ust applications close the 
> new list of shm fds and free new shm resource but keeping old shm still. In 
> other word, we can not free this piece of shm unless we killing ust 
> applications!!!
>   So Is there any possilbe that ust applications failed calling 
> lttng_ust_objd_table_owner_cleanup()? Do you have ever see this problem? Do 
> you have any advice to free the shm without killling ust applications(I tried 
> to dig into kernel shm_open and /dev/shm, but not found any ideas)?
> 
> Thanks in advance
> zhenyu.ren 
> 
> 
> 
> --
> 发件人：zhenyu.ren via lttng-dev 
> 发送时间：2022年2月23日(星期三) 23:09
> 收件人：lttng-dev 
> 主　题：[lttng-dev] 回复： shm leak in traced application?
> 
> >"I found these items also exist in a traced application which is a long-time 
> >running daemon"
>  Even if lttng-sessiond has been killed!!
> 
> Thanks
> zhenyu.ren
> --
> 发件人：zhenyu.ren via lttng-dev 
> 发送时间：2022年2月23日(星期三) 22:44
> 收件人：lttng-dev 
> 主　题：[lttng-dev] shm leak in traced application?
> 
> Hi, 
>There are many items such as "/dev/shm/ust-shm-consumer-81132 (deleted)" 
> exist in lttng-sessiond fd spaces. I know it is the result of shm_open() and 
> shm_unlnik() in create_posix_shm(). 
>However, today, I found these items also exist in a traced application 
> which is a long-time running daemon. The most important thing I found is that 
> there seems no reliable way to release share memory.
>I tried to kill lttng-sessiond but not always release share memory. 
> Sometimes I need to kill the traced application to free share memoryBut 
> it is not a good idea to kill these applications.
>My questions are: 
>1. Is there any way to release share memory without killing any traced 
> application?
>2. Is it normal that many items such as "/dev/shm/ust-shm-consumer-81132 
> (deleted)" exist in the traced application?
> 
> Thanks
> zhenyu.ren
> 
> 

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


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

Re: [lttng-dev] Transfer of LTTng copyright ownership: Jonathan Rajotte-Julien

[Jonathan Rajotte via lttng-dev]

Yes. I agree.



On Thu, Jan 20, 2022 at 10:24 AM Mathieu Desnoyers <
mathieu.desnoy...@efficios.com> wrote:

> Hi Jonathan,
>
> In order to facilitate maintenance of the LTTng project, would you agree to
> transfer your copyright ownership for code authored outside of your
> employment
> at EfficiOS to EfficiOS Inc. ?
>
> This particularly affects the lttng-tools files with copyright:
>
>   Copyright (C) 201N Jonathan Rajotte 
>
> Thanks!
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>


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

Re: [lttng-dev] [PATCH] lttng-ust-common: link with liburcu explicitly

[Jonathan Rajotte-Julien via lttng-dev]

Hi Alexander,

Thanks for sending this patch. Could you provide more details regarding the 
linking errors?

lttng-ust must not depends on liburcu at runtime since commit 
10544ee8af31afb239e3dfa71cb2fe09d3de3771

commit 10544ee8af31afb239e3dfa71cb2fe09d3de3771
Author: Mathieu Desnoyers 
Date:   Wed Nov 11 17:28:06 2020 -0500

Remove runtime dependency on liburcu shared objects

Remove the runtime dependency on:

- liblurcu-bp.so
- liblurcu-cds.so
- compat futex code.

By integrating those into the lttng-ust project.

For rculfhash, only the minimum pieces needed by lttng-ust are
integrated (no auto-resize, no accounting).

lttng-ust still requires liburcu at build time for header dependencies.

Signed-off-by: Mathieu Desnoyers 
Change-Id: Idffb205b27b1bb0f972523c3ce3bdaf25bfe1710


Cheers 

- Original Message -
> From: "Alexander Kanavin" 
> To: "lttng-dev" , "Francis Deslauriers" 
> , "jonathan
> rajotte-julien" 
> Cc: "Alexander Kanavin" 
> Sent: Thursday, December 2, 2021 3:04:12 PM
> Subject: [PATCH] lttng-ust-common: link with liburcu explicitly

> Otherwise linking errors are seen on x86-32.
> ---
> src/lib/lttng-ust-common/Makefile.am | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/src/lib/lttng-ust-common/Makefile.am
> b/src/lib/lttng-ust-common/Makefile.am
> index caeea2be..0130628c 100644
> --- a/src/lib/lttng-ust-common/Makefile.am
> +++ b/src/lib/lttng-ust-common/Makefile.am
> @@ -15,6 +15,7 @@ liblttng_ust_common_la_SOURCES = \
> 
> liblttng_ust_common_la_LIBADD = \
>   $(top_builddir)/src/common/libcommon.la \
> + $(URCU_LIBS) \
>   $(DL_LIBS)
> 
> liblttng_ust_common_la_LDFLAGS = -no-undefined -version-info
> $(LTTNG_UST_LIBRARY_VERSION)
> --
> 2.20.1
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] quick question about setting up lttng on Redhat

[Jonathan Rajotte-Julien via lttng-dev]

Hello,

On Mon, Jul 19, 2021 at 09:40:06AM -0400, Evan Galea via lttng-dev wrote:
> Hello there
> 
> We have been considering setting up Redhat on my system and have learned
> that Lttng packages are supported. I was hoping to quickly learn the answer

EfficiOS provides commercial support for RedHat. Please contact
sa...@efficios.com if you need commercial support.

> to two questions:
> 
> 1: As Redhat is based on Fedora, Do I just use the instructions for Fedora?
> I know it's probably a stupid question but I just want to make sure I'm
> doing everything correctly.

I do not think so, since the packages repository are not the same AFAIK.

If you are using RHEL 7 and okai with using lttng 2.10, you can have a look here
http://packages.efficios.com/

Installing from source is also a possibility. The only major hurdle might be
lttng-modules depending on your kernel version.

> 
> 2: Are there any differences between Lttng on Redhat and Lttng on Ubuntu or
> are they simply the same? Again just need to make absolutely sure as I
> don't want to do anything without first knowing

At the functionality level, it will be the same. Distros do not influence the
functionality we expose. At least not for now...

For Ubuntu, the lttng project have multiple PPA depending on your need.

https://launchpad.net/~lttng

> 
> Thank you for your time and sorry if the answers to these questions are
> somewhere I didn't look.
> 
> Evan Galea

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


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

Re: [lttng-dev] LTTng 32 bits on 64 bits systems - kernel events... but no user-event

[Jonathan Rajotte-Julien via lttng-dev]

Hi Julien,

A fix is on the way for libfd-tracker lib problem: 

https://review.lttng.org/c/lttng-tools/+/6045 

> Thank you ! The following modification is working :
> lttng-sessiond --consumerd32-libdir=/usr/local/lib32
> --consumerd32-path=/usr/local/lib32/lttng/libexec/lttng-consumerd --daemonize

Glad we could help.

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

Re: [lttng-dev] LTTng 32 bits on 64 bits systems - kernel events... but no user-event

[Jonathan Rajotte-Julien via lttng-dev]

Hi, 

> I am currently trying to add lttng 32bits on a 64bits system with a custom
> kernel 4.19.177+ x86_64 (Debian 10.9)
> My former attempt only with only a 100% arm32 bits was successful (raspberry).
> I am facing now a strange issue : I can record kernel event but not userspace
> event... but I can see these user-event (see below)!

Ok. 

> (tuto : [ 
> https://lttng.org/docs/#doc-instrumenting-32-bit-app-on-64-bit-system
> | https://lttng.org/docs/#doc-instrumenting-32-bit-app-on-64-bit-system ] )

> I followed two times the tutorial : on lttng 2.12 and lttng 2.10.
> I am on lttng (LTTng Trace Control) 2.10.11 - KeKriek now

Any particular reasons?

> All installation seemed to install without any error.
> The only thing I added is at the very end where I did a : ln -s
> /usr/local/bin/lttng /usr/bin/lttng (to directly call commands like "lttng
> start")

> Here some interesting outputs, I am using this projet as an example : [
> https://lttng.org/docs/#doc-tracing-your-own-user-application |
> https://lttng.org/docs/#doc-tracing-your-own-user-application ]
> lttng list -u : OK [ https://paste.ubuntu.com/p/hZptnNzySw/ | Ubuntu Pastebin 
> ]
> LTTNG_UST_DEBUG=1 ./hello : seems OK : [ 
> https://paste.ubuntu.com/p/w6xHrJsWJ9/
> | Ubuntu Pastebin ]
> kernel-event output : [ https://paste.ubuntu.com/p/5KfyS8wVdb/ | Ubuntu 
> Pastebin
> ]
> user-event ouput : none - the output folder stated with lttng create
> my-user-session --output=/tmp/my-user-session doesn't even appear
> apt-file search lttng : [ https://paste.ubuntu.com/p/xMcCc7bqwk/ | Ubuntu
> Pastebin ]
> lsmod | grep lttng : [ https://paste.ubuntu.com/p/7YNkNsh9Fr/ | Ubuntu 
> Pastebin
> ]

Can you provide the config.log from the configure steps 

We are missing the most important logs: lttng-sessiond. 

$ lttng-sessiond -vvv --verbose-consumer 

> Note : file /usr/local/bin/lttng (the exe I am using) gives :
> /usr/local/bin/lttng: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
> 3.2.0, BuildID[sha1]=542a108c40e386c17027c2c8f8fcb30e278b7748, with 
> debug_info,
> not stripped

This is normal. Concretely to support tracing of 32 bit applications only a 32 
bits
lttng-consumerd executable is needed which is launched by the lttng-sessiond 
executable. 

> I am wondering if the installation didn't pick a 64bits RCU and analyses
> programms only on this.

Hmmm, what indicate this? I seriously doubt that this can happen. 

> However, I have currently absolutely no idea how to debug this.

I decided to do the process on a clean ubuntu 20.04 machine.
For 2.12 there is some problems when compiling only lttng-consumerd (fd-tracker 
lib and libcommon problem). I plan on providing a patch shortly.

But the major problem is that the path passed at configure time for the 
lttng-consumerd32 bit daemon are simply not used at runtime.
See this bug I just opened [1]. This is valid for 2.10 all the way to master 
AFAIK.

[1] https://bugs.lttng.org/issues/1318 

In the meantime you will have to pass the lttng-consumerd 32 bit path as 
argument or env variables to lttng-sessiond as such: 

$ lttng-sessiond -vvv --verbose-consumer --consumerd32-libdir=/usr/local/lib32 
--consumerd32-path=/usr/local/lib32/lttng/libexec/lttng-consumerd

or 

$ LTTNG_CONSUMERD32_BIN=/usr/local/lib32/lttng/libexec/lttng-consumerd 
LTTNG_CONSUMERD32_LIBDIR=/usr/local/lib32 lttng-sessiond -vvv --verbose-consumer


>From there the 32bits application is traced correctly and data is gathered 
>without any problem (at least on 2.12).


```
[15:22:24.500655502] (+?.?) ubuntu2004.localdomain 
lttng_ust_statedump:start: { cpu_id = 3 }, { }
[15:22:24.500661538] (+0.06036) ubuntu2004.localdomain 
lttng_ust_statedump:procname: { cpu_id = 3 }, { procname = "hello" }
[15:22:24.502611224] (+0.001949686) ubuntu2004.localdomain 
lttng_ust_statedump:bin_info: { cpu_id = 3 }, { baddr = 0xF7EC9000, memsz = 
20596, path = "/usr/lib32/libdl-2.31.so", is_pic = 1, has_build_id = 1, 
has_debug_link = 1 }
[15:22:24.502614501] (+0.03277) ubuntu2004.localdomain 
lttng_ust_statedump:build_id: { cpu_id = 3 }, { baddr = 0xF7EC9000, 
_build_id_length = 20, build_id = [ [0] = 0x75, [1] = 0x1E, [2] = 0xDD, [3] = 
0x47, [4] = 0x72, [5] = 0x3, [6] 
```

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

Re: [lttng-dev] Syntax error running lttng

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

Side note: not sure what is wrong with my email setup or the mailing list but I
cannot see the reply you sent in my email folder, but it is available here: 

https://lists.lttng.org/pipermail/lttng-dev/2021-June/030021.html

In any case, this look strangely like the problem seen in [1][2]. Considering
your cross compilation setup I would take a deeper look at the generated
executable both locally and when on the device.
The `file` command is a must here I think.

[1] 
https://unix.stackexchange.com/questions/336436/syntax-error-unexpected-when-execute-a-compiled-c-program
[2] 
https://unix.stackexchange.com/questions/499641/syntax-error-unexpected-when-execute-a-cross-compiled-pjsip-binary-in-arm

Not sure if this is exactly your problem. `strace` might give a bit more info
on what is going on and at least see if the problem is lttng or anything else. 

Cheers

On Tue, Jun 01, 2021 at 10:48:13AM +1000, Merlin via lttng-dev wrote:
> Hi,
> 
>  
> 
> I have compiled LTTNG for ARM but when I try to run the executable, I get
> this error:
> 
>  
> 
> lttng: line 1: syntax error: unexpected "("
> 
>  
> 
> E.G.lttng create my-kernel-session
> --output=/mnt/sd1/nfs/temp/Innotech/lttng/my-kernel-trace
> 
> lttng list --kernel
> 
> lttng-sessiond
> 
>   all produce the same error.
> 
>  
> 
> There were no compiler errors.  I am at a loss to understand what it is
> complaining about from the message.
> 
>  
> 
> Modules seem to load fine.
> 
>  
> 
> ~ # lsmod
> 
> Module  Size  Used byTainted: G
> 
> lttng_ring_buffer_client_discard20480  0
> 
> lttng_ring_buffer_client_mmap_discard20480  0
> 
> lttng_ring_buffer_metadata_mmap_client16384  0
> 
> lttng_ring_buffer_metadata_client16384  0
> 
> lttng_ring_buffer_event_notifier_client16384  0
> 
> lttng_ring_buffer_client_overwrite20480  0
> 
> lttng_tracer 1167360  6
> lttng_ring_buffer_client_discard,lttng_ring_buffer_client_mmap_discard,lttng
> _ring_buffer_metadata_mmap_client,lttng_ring_buffer_metadata_client,lttng_ri
> ng_buffer_event_notifier_client,lttng_ring_buffer_client_overwrite
> 
> lttng_kprobes  16384  1 lttng_tracer
> 
> lttng_lib_ring_buffer57344  7
> lttng_ring_buffer_client_discard,lttng_ring_buffer_client_mmap_discard,lttng
> _ring_buffer_metadata_mmap_client,lttng_ring_buffer_metadata_client,lttng_ri
> ng_buffer_event_notifier_client,lttng_ring_buffer_client_overwrite,lttng_tra
> cer
> 
> lttng_kretprobes   16384  1 lttng_tracer
> 
> lttng_statedump20480  1 lttng_tracer
> 
> lttng_wrapper  16384  2 lttng_tracer,lttng_statedump
> 
> lttng_clock16384  4
> lttng_ring_buffer_client_discard,lttng_ring_buffer_client_mmap_discard,lttng
> _ring_buffer_client_overwrite,lttng_tracer
> 
>  
> 
> Any suggestions appreciated.
> 
>  
> 
> Thank you.
> 
>  
> 
> Merlin
> 

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


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

Re: [lttng-dev] Syntax error running lttng

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Tue, Jun 01, 2021 at 10:48:13AM +1000, Merlin via lttng-dev wrote:
> Hi,
> 
>  
> 
> I have compiled LTTNG for ARM but when I try to run the executable, I get
> this error:

Do you have any of the logs for the lttng-tools project?

That would be `config.log` and the output from `make` and `make install`

> 
>  
> 
> lttng: line 1: syntax error: unexpected "("

Hmmm that does not look like an error from a elf executable.

Do you have any bash or shell alias for the lttng command?

Please provide the output of the following commands:
  $ file $(which lttng)
  $ head -n 10 $(which lttng)



> lttng-sessiond

If this happens also on the `lttng-sessiond` via command line but works using a
service, it would point to weird shell setup.
> 
>   all produce the same error.
> 
>  
> 
> There were no compiler errors.  I am at a loss to understand what it is
> complaining about from the message.

Me too.

> 
>  
> 
> Modules seem to load fine.

Modules are loaded by the lttng-sessiond executable. Here only the CLI
executable seems to be having some problem.

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

Re: [lttng-dev] lttng live event loss with babeltrace2

[Jonathan Rajotte-Julien via lttng-dev]

Hi, 

> I ran my test with the new changes and it seems to improve the lossiness but 
> not
> eliminate it. For example it seems in the hello world example that if the
> application exits too quickly after emitting the tracepoint, we might still
> lose some events in the consumer even though they are present in the relayd
> output folder.

Here by consumer you mean a "live reader" right? If so I would suggest you use 
the term 
"live consumer reader" or "live reader" since "consumer" alone can yield some 
confusion 
with lttng-consumerd. 

I would need a reproducer for this, you can base yourself on the reproducer in 
the commit message for the previous fix. 
AFAIK there is no valid reason for this to happen, at 
least based on my review of the code for the fix we just merged.
(This is only valid for per-uid tracing, per-pid tracing and lttng live have 
not so minor limitation inherent to the current lttng-live implementation) 

> I don't quite understand why that is. Would love some explanations on the
> various timing windows where we have a potential to lose the events on the
> consumer side.

>From a live reader perspective, in per-uid mode, there should be no "loss" of 
>event from the moment the viewer is attached and 
the moment it detach. Here "loss" mean that the events are present in the trace 
gathered by lttng-relayd but not by the live 
reader for the same "time window". This is only valid if the viewer is not 
"late" and have consumed everything at the moment it detach.


Cheers

- Original Message -
> From: "Eqbal" 
> To: "Jonathan Rajotte-Julien" 
> Cc: "lttng-dev" 
> Sent: Monday, May 10, 2021 8:35:41 PM
> Subject: Re: [lttng-dev] lttng live event loss with babeltrace2

Hi, 

> I ran my test with the new changes and it seems to improve the lossiness but 
> not
> eliminate it. For example it seems in the hello world example that if the
> application exits too quickly after emitting the tracepoint, we might still
> lose some events in the consumer even though they are present in the relayd
> output folder.

Here by consumer you mean a "live reader" right? If so I would suggest you use 
the term "live consumer reader" or "live reader" since "consumer" alone can 
yield some confusion with lttng-consumerd. 

I would need a reproducer for this, you can base yourself on the reproducer in 
the commit message for the previous fix. 
AFAIK there is no valid reason for this to happen, at least based on my review 
of the code for the fix we just merged. (This is only valid for per-uid 
tracing, per-pid tracing and lttng live have not so minor limitation inherent 
to the current lttng-live implementation) 

> I don't quite understand why that is. Would love some explanations on the
> various timing windows where we have a potential to lose the events on the
> consumer side.

>From a live reader perspective, in per-uid mode, there should be no "loss" of 
>event from the moment the viewer is attached and the moment it detach. Here 
>"loss" mean that the events are present in the trace gathered by lttng-relayd 
>but not by the live reader for the same "time window". This is only valid if 
>the viewer is not "late" and have consumed everything at the detach moment. 

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

Re: [lttng-dev] lttng live event loss with babeltrace2

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

See 
https://github.com/lttng/lttng-tools/commit/c876d657fb08a91ca7c907b92f1b7604aee664ee
 . 

We would appreciate your feedback on this if possible based on your use case.

Cheers

On Mon, May 03, 2021 at 05:05:10PM -0700, Eqbal via lttng-dev wrote:
> Hi,
> 
> I have a lttng live session trace consumer application using libbabeltrace2
> where I create a graph to consume lttng live session traces and output to
> another sink. I am running the graph in a loop at some polling interval as
> long as I get BT_GRAPH_RUN_STATUS_AGAIN status. What I am noticing is that
> if my polling interval is large enough I tend to lose either all or some of
> the events. I experimented with various polling intervals and it seems if
> the polling interval is less than *DELAYUS *from "lttng-create
> --live=DELAYUS" option then I am able to get all the events, otherwise I
> tend to lose events.
> 
> Here are the steps I follow:
> 1. start session daemon and relay daemon
> 2. create a live session (with default delay of 1s), enable events and start
> 3. Start my application (hello world example from lttng docs)
> 4. Start the consumer application built using libbabeltrace that connects
> to the live session
> 
> I noticed that the events are actually persisted in the ~/lttng-traces by
> the relay daemon, but it does not reach babeltrace consumer application. I
> have noticed the same behavior with babeltrace2 cli.
> 
> I would like to understand what is the reason for such behavior and if
> playing with the polling interval in relation to the DELAYUS value is the
> right thing to do.
> 
> Thanks,
> Eqbal

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


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

Re: [lttng-dev] lttng live event loss with babeltrace2

[Jonathan Rajotte-Julien via lttng-dev]

On Mon, May 03, 2021 at 05:05:10PM -0700, Eqbal via lttng-dev wrote:
> Hi,
> 
> I have a lttng live session trace consumer application using libbabeltrace2
> where I create a graph to consume lttng live session traces and output to
> another sink. I am running the graph in a loop at some polling interval as
> long as I get BT_GRAPH_RUN_STATUS_AGAIN status. What I am noticing is that
> if my polling interval is large enough I tend to lose either all or some of
> the events. I experimented with various polling intervals and it seems if
> the polling interval is less than *DELAYUS *from "lttng-create
> --live=DELAYUS" option then I am able to get all the events, otherwise I
> tend to lose events.
> 
> Here are the steps I follow:
> 1. start session daemon and relay daemon
> 2. create a live session (with default delay of 1s), enable events and start
> 3. Start my application (hello world example from lttng docs)

Not sure if you modified it in any way, but be careful with short lived apps
since an app can terminate before lttng-ust have a chance to register.

> 4. Start the consumer application built using libbabeltrace that connects
> to the live session

hmm. Note that when attaching to a session it does not start at the beginning 
of the
trace collected by lttng-relayd, it start at the last received data from
lttng-relayd from the lttng-consumerd (LTTNG_VIEWER_SEEK_LAST).

Hence I would recommend that these steps be inversed:

4. Start the consumer application built using libbabeltrace that connects
to the live session
3. Start my application (hello world example from lttng docs)


> 
> I noticed that the events are actually persisted in the ~/lttng-traces by
> the relay daemon, but it does not reach babeltrace consumer application. I
> have noticed the same behavior with babeltrace2 cli.
> 
> I would like to understand what is the reason for such behavior and if
> playing with the polling interval in relation to the DELAYUS value is the
> right thing to do.

I think I reproduced the issue but I'm not completely sure it is the same
problem. Please file an issue on the bug tracker [1] with
as much information as possible, the exact lttng
commands used, the current behaviour and the expected behaviour. 
I'll add my findings if relevant.

But I think it might be a weird handling of how we handle the first "empty"
retry and the subsequent get phase. After the initial phase everything seems to
work as expected.

[1] https://bugs.lttng.org/


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

Re: [lttng-dev] lttng live event loss with babeltrace2

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Mon, May 03, 2021 at 05:05:10PM -0700, Eqbal via lttng-dev wrote:
> Hi,
> 
> I have a lttng live session trace consumer application using libbabeltrace2
> where I create a graph to consume lttng live session traces and output to
> another sink. I am running the graph in a loop at some polling interval as
> long as I get BT_GRAPH_RUN_STATUS_AGAIN status. What I am noticing is that
> if my polling interval is large enough I tend to lose either all or some of
> the events. I experimented with various polling intervals and it seems if
> the polling interval is less than *DELAYUS *from "lttng-create
> --live=DELAYUS" option then I am able to get all the events, otherwise I
> tend to lose events.
> 
> Here are the steps I follow:
> 1. start session daemon and relay daemon
> 2. create a live session (with default delay of 1s), enable events and start
> 3. Start my application (hello world example from lttng docs)
> 4. Start the consumer application built using libbabeltrace that connects
> to the live session
> 
> I noticed that the events are actually persisted in the ~/lttng-traces by
> the relay daemon, but it does not reach babeltrace consumer application. I
> have noticed the same behavior with babeltrace2 cli.

Could you also test against babeltrace 1.5? It might give us a bit of a head
start to debug this if it turns out to be unexpected behaviour.

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

Re: [lttng-dev] lttng-dev Digest, Vol 156, Issue 3

[Jonathan Rajotte-Julien via lttng-dev]

> I followed your command sequence and noticed a bunch of files being
> created. However when I tried to run babeltrace on these outputs I don't
> see any of the functions that should have been called.  Including below the
> search for symbols.

At least userspace tracing seems to work.

I would recommended, again, that you first try tracing on a dummy application, a
really simple one. Then move to the usage of cyg_profile on that dummy app then
to your application.

The cyg profile events are the following:

  lttng_ust_cyg_profile_fast:func_entry
  lttng_ust_cyg_profile_fast:func_exit

and, when using liblttng-ust-cyg-profile.so:

  lttng_ust_cyg_profile:func_entry
  lttng_ust_cyg_profile:func_exit

I would recommend that you first start grep-ing (lttng_ust_cyg) for this in the
trace to see if any is getting hit and recorded. If it is not the case, take a
step back try with a dummy app and if nothing works with the dummy app we can at
least try to help you from there and remove all other variable since you will be
able to share the dummy app with us.

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

Re: [lttng-dev] Userspace tracing in docker containers

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Mon, Apr 05, 2021 at 11:09:39AM -0700, Eqbal via lttng-dev wrote:
> Hi,
> 
> I am trying to get user space tracing working for an application running in
> a docker container. I am running lttng session daemon in another container.
> I mounted the unix socket locations (either /var/run/lttng for root or
> $HOME/.lttng for another user). By doing that I can run commands like lttng
> create or lttng list , but the tracepoint events from the
> application don't get registered and there is no trace output.
> 
> I enabled LTTNG_UST_DEBUG an ran lttng-sessiond in verbose mode (-vvv and
> --verbose-consumer) and got the following error message:
> 
> "*Unix socket credential pid=0. Refusing application in distinct,
> non-nested pid namespace.*"
> 
> It appears that for some calls to the session daemon there is a getsockopt
> syscall made with *SO_PEERCRED* which returns 0 for pid and the call is
> failed with *LTTNG_UST_ERR_PEERCRED_PID* error (see get_cred call in
> ustctl.c).
> 
> If I comment out the getsockopt call, my application tracing starts to work.
> 
> From what I found, docker cannot support getsockopt/SO_PEERCRED call to get
> peer pid on the unix socket which would make sense as it's in a separate
> namespace.
> 
> I have a few questions on this:
> 1. What is the reason for the get_cred/getsockopt call with SO_PEERCRED? I
> would like to understand why it's required for some and not other calls.


More information is found in the introducing commit:

  commit a834901f2890deadb815d7f9e3ab79c3ba673994
  Author: Mathieu Desnoyers 
  Date:   Mon Oct 12 16:52:03 2020 -0400

Fix: Use unix socket peercred for pid, uid, gid credentials

Currently, the session daemon trust the pid, ppid, uid, and gid values
passed by the application, but should really validate the uid using unix
socket peercred. This fix uses the peercred values rather than the
values provided by the application on registration for:

- pid, uid and gid on Linux,
- uid and gid on FreeBSD.

This should improve how the session daemon deals with containerized
applications on Linux as well. Applications are required to be either in
the same pid namespace, or in a pid namespace nested within the pid
namespace of the lttng-sessiond, so the session daemon can map the
application pid to something meaningful within its own pid namespace.
Applications in a unrelated (disjoint) pid namespace will be refused by
the session daemon.

About the uid and gid with user namespaces on Linux, those will provide
meaningful IDs if the application user namespace is either the same as
the user namespace of the session daemon, or a nested user namespace.
Otherwise, the IDs will be that of /proc/sys/kernel/overflowuid and
/proc/sys/kernel/overflowgid, which typically maps to nobody.nogroup on
current distributions.

Given that fetching the parent pid (ppid) of the application would
require to use /proc//status (which is racy wrt pid reuse), expose
the ppid provided by the application on registration instead, but only
in situations where the application sits in the same pid namespace as
the session daemon (on Linux), which is detected by checking if the pid
provided by the application matches the pid obtained using unix socket
credentials. The ppid is only used for logging/debugging purposes in the
session daemon anyway, so it is OK to use the value provided by the
application for that purpose.

Fixes: #1286
Signed-off-by: Mathieu Desnoyers 
Change-Id: I94742e57dad642106908d09e2c7e395993c2c48f

As for "why it's required for some and not other calls.", there is a difference
between communicating with a lttng-sessiond daemon (using the lttng CLI) and
userspace application registering. They are essentially two distinct
communication interface. Now, to be honest, I'm not certain of the complete
"security" policy for the lttng-sessiond <-> CLI interface and if we should be
more strict or not.

> 2. Is there any workaround for this problem, so that I can get this to work
> with the container topology I am working with (app in one container and
> lttng daemons in another).

Based on the commit message, lttng-ust explicitly cannot be used across
non-nested pid namespace.

Could you give us more information on the goal for the topology you plan to use?
This could lead to further discussion and/or alternative solution based on the
goal and constraints of your deployment.

> 3. Related to 2, are there any gotchas to bypassing the getsockopt call in
> get_cred?

Based on the content of the mentioned bug (1286) [1],  the principal concern is:

"
This means a non-root application could theoretically impersonate a root
application from a tracing perspective, and thus access root tracing

Re: [lttng-dev] lttng-dev Digest, Vol 156, Issue 3

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

I think you need to take a step back and figure out how lttng is deployed and 
more
importantly the overall architecture of lttng and its principal moving pieces.

First, you need a functioning and running lttng-sessiond process.

>From lttng-console-log.txt:

   root@RocrLnx23:~/git/compute/out/ubuntu-18.04/18.04/bin#  lttng list -u
   Error: Unable to list UST events: No session daemon is available

The error is clear here, no lttng-sessiond is running or at least, the lttng CLI
cannot communicate with it.

Here the sessiond was killed before performing this operation based on
CmdSequence.txt. You seem to have forgot to start a lttng-sessiond before
performing the call to your application and `lttng` commands.

My previous email stated the following:
  With the app running and having the LD_PRELOAD correctly set, and a sessiond
  (sessiond should have read lttng-sessiond) running.

Then, if we look at kernel modules loading.

>From lttng-sessiond.txt:

DEBUG1 - 19:50:34.293777619 [27093/27093]: libkmod: could not find module by 
name='lttng_ring_buffer_client_discard'
 (in log_kmod() at modprobe.c:108)
Error: Unable to load required module lttng-ring-buffer-client-discard
Warning: No kernel tracer available

libkmod expect the presence of lttng-modules kernel modules in: 
/lib/modules/$(uname -r)/

>From lttng-system-env.txt:

  root@RocrLnx23:~# find /lib/modules/$(uname -r)/ | grep lttng

Yield nothing. I suspect that your modules are installed under:

  ~/git/compute/out/ubuntu-18.04/18.04/lib/modules/$(uname -r)/

Now, currently, lttng-sessiond when built with kmod support does not support
defining the modules locations (as far as I know) since we pass (NULL, NULL)
to the creation context (kmod_new). The default behaviour is to look into
/lib/modules/ .

Albeit it would be nice to support such scenarios, this will not help you in the
short term. I would recommend the usage of symbolic link here to provide 
"/lib/modules/$(uname -r)/".

Note that this is overly complicated by the deployment scenario you are
currently using, which does not represent a typical deployment for most of our
users.

In any cases, again, this is only useful if you plan on doing kernel tracing. 

I would suggest that you might want to put effort in making sure Userspace
Tracing works.

Here I think the only thing missing is to have a running lttng-sessiond process
while you launch  ./rocminfo

Concretely:
$ sudo -s
# systemctl stop lttng-sessiond.service
# pkill lttng-sessiond
# cd ~/git/compute/out/ubuntu-18.04/18.04/lib
# export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
# lttng-sessiond -vvv --verbose-consumer -b > /tmp/lttng-sessiond.log 2>&1
# lttng create my_userspace_tracing_session
# lttng enable-event -u -a
# lttng start
# LD_PRELOAD=liblttng-ust-cyg-profile-fast.so  LTTNG_UST_DEBUG=1 
./rocminfo
# lttng destroy
# babeltrace 
# pkill lttng-sessiond


Note: here the manual starting and termination of lttng-sessiond is only for the
purpose of testing. In a normal deployment lttng-sessiond is a daemon.

Note that the sequence of `lttng` commands is important here since I expect
./rocminfo to not have a long lifetime. In other word, the `rocminfo` will have
finished and unregistered from lttng-sessiond perspective before you are able to
manually either list its tracepoints or setup a tracing session after you 
started
the application.

Please read the following and try to perform it under your deployment scenario:

https://lttng.org/docs/v2.12/#doc-tracing-your-own-user-application


Hope this helps.

Cheers


On Mon, Apr 05, 2021 at 08:32:00PM -0500, Ramesh Errabolu via lttng-dev wrote:
> Jonathan, et al
> 
> Attaching here with logs of the run.
> 
> 1. Command sequence I ran
> 2. Console log of commands as I ran them
> 3. Log of lttng-service daemon *lttng-sessiond.txt*
> 4. Info about the system, things such as kernel, lttng kernel modules, etc
> 5. Lastly I tried to build lttng-modules for my kernel 5.9.x. This failed
> as lacking support for it.
> 
> Any help info is appreciated.
> 
> Regards,
> Ramesh
> 
> 
> On Fri, Apr 2, 2021 at 11:00 AM  wrote:
> 
> > Send lttng-dev mailing list submissions to
> > lttng-dev@lists.lttng.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> > or, via email, send a message with subject or body 'help' to
> > lttng-dev-requ...@lists.lttng.org
> >
> > You can reach the person managing the list at
> > lttng-dev-ow...@lists.lttng.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of lttng-dev digest..."
> >
> >
> > Today's Topics:
> >
> >1. Re: Can't trac

Re: [lttng-dev] Can't trace function calls

[Jonathan Rajotte-Julien via lttng-dev]

On Wed, Mar 31, 2021 at 12:55:53PM -0500, Ramesh Errabolu wrote:
> root@RocrLnx23:~/git/compute/out/ubuntu-18.04/18.04/bin# ls ~/ | grep -i ltt
> root@RocrLnx23:~/git/compute/out/ubuntu-18.04/18.04/bin# lttng create
> my-kernel-session --output=~/my-kernel-trace
> Session my-kernel-session created.
> Traces will be output to
> /home/user1/git/compute/out/ubuntu-18.04/18.04/bin/~/my-kernel-trace
> root@RocrLnx23:~/git/compute/out/ubuntu-18.04/18.04/bin# *lttng list
> --kerne*l
> *Error: Unable to list kernel events: Kernel tracer not available*

Well this would be the first thing to look at.

First let's deactivate the lttng-sessiond.service installed by the packages.

   systemctl stop lttng-sessiond.service

You might want to reanable it later.

> 
> root@RocrLnx23:~/git/compute/out/ubuntu-18.04/18.04/bin# ps -ef | grep ltt
> root  1002 1  0 12:16 ?00:00:00 /usr/bin/lttng-sessiond
> root  1054  1002  0 12:16 ?00:00:00 */usr/bin/lttng-sessiond*
> root  3145  2861  0 12:51 pts/000:00:00 grep --color=auto ltt
> root@RocrLnx23:~/git/compute/out/ubuntu-18.04/18.04/bin#

Make sure after the systemctl call that no lttng-sessiond process is running.

Now let's launch a lttng-sessiond by hand with a bit more verbosity. For now
let's stick to the root user.

  # lttng-sessiond -vvv --verbose-consumer -b > /tmp/lttng-sessiond.log 2>&1 
  # pkill lttng-sessiond

Please share the content of /tmp/lttng-sessiond.log using a pasting service
(paste.ubuntu.com).

Also please provide the output of:

 # uname -a
 # find /lib/modules/$(uname -r)/ | grep lttng
 # dmesg | grep lttng


But again, the cyg-profile helper library is meant for Userspace tracing.

With the app running and having the LD_PRELOAD correctly set, and a sessiond
running.

 # lttng list -u 

If there is nothing, well you can start the application with the following and
share the output of it (make sure to remove any output from your application if
sensitive data is present)

 # LD_PRELOAD= LTTNG_UST_DEBUG=1 your_application_here

Note that debug log will be outputted on stderr.

Cheers

-- 
Jonathan Rajotte-Julien
EfficiOS
___
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: test code assumes that child process is schedule to run before parent

[Jonathan Rajotte-Julien via lttng-dev]

On Thu, Apr 01, 2021 at 03:21:10AM +0200, Anders Wallin wrote:
> Hi Jonathan :)
> 
> It's very unlikely that the race could occur, BUT it can happen.
> 
> OK run
> 1. test_event_tracker starts gen-ust-events
> 2. test_event_tracker waits for gen-ust-events to create AFTER_FIRST_PATH
> 3. gen-ust-event create first event and create AFTER_FIRST_PATH
> 4. gen-ust-event continue and create 99 events
> 5. gen-ust-event wait for  BEFORE_LAST_PATH
> 6. test_event_track start collecting events (lttng start .)

> 7. test_event_tracker calls "lttng track ... -pid "Faulty PID"
> 8. test_event_tracker touches BEFORE_LAST_PATH
> 9. gen-ust-events creates the last event
> 10. test_event finishes and since it tracks the faulty pid the result will
> be 0 events == OK

The sequence of event for the `test_event_tracker` function is (as of master):

create
enable event
start
track

launch app
wait for app return
stop
destroy


The sequence you are describing here is:

lauch app
start
track
...

I'm pretty sure we are not talking about the same things. Please specify the
test case and all functions involved and make sure to use the proper name for
each of them.

I suspect you are talking about test_event_pid_tracker. Still let's make sure of
it. If it is, I do agree that it seems to have a window where we can gather
event for.

You might want to look if there is a real reason for this sequence instead of
mimicking test_event_tracker

Current code:
 enable_"$domain"_lttng_event_ok $SESSION_NAME "$wildcard" "$channel"
 prepare_"$domain"_app
 start_lttng_tracing_ok

 if [ "$expect_event" -eq 1 ]; then
 lttng_track_"$domain"_ok "--vpid ${CHILD_PID}"
 else
 lttng_track_"$domain"_ok "--vpid $((CHILD_PID+1))"
 fi
 trace_"$domain"_app
 stop_lttng_tracing_ok
 destroy_lttng_session_ok $SESSION_NAME


We might simply want to move the track command before the start considering have
all the information to do so.

 enable_"$domain"_lttng_event_ok $SESSION_NAME "$wildcard" "$channel"

 prepare_"$domain"_app

 if [ "$expect_event" -eq 1 ]; then
 lttng_track_"$domain"_ok "--vpid ${CHILD_PID}"
 else
 lttng_track_"$domain"_ok "--vpid $((CHILD_PID+1))"
 fi

 start_lttng_tracing_ok
 trace_"$domain"_app

 stop_lttng_tracing_ok
 destroy_lttng_session_ok $SESSION_NAME

After testing this, seems like the validate_trace_empty does not handle the
case were simply stream allocation did not take place since no application was
'valid' at the moment of the trace start.

Well we got a good one here. We will wait for your updated patch and go from
there.

Cheers

> 
> Faulty run
> 1. test_event_tracker starts gen-ust-events
> 2. test_event_tracker waits for gen-ust-events to create AFTER_FIRST_PATH
> 3. gen-ust-event create first event and create AFTER_FIRST_PATH
> 4. gen-ust-event gets rescheduled before it has created 99 events, e.g
> after 9 events
> 5. test_event_track start collecting events (lttng start .)
> 6. gen-ust-event is rescheduled and starts generating the remaining events.
> 90 events
> 7. lttng collects these 90 events since we have not setup "tracking" of PID
> yet
> 8. test_event_tracker calls "lttng track ... -pid "Faulty PID"
> 9. test_event_tracker touches BEFORE_LAST_PATH
> 10. gen-ust-events creates the last event
> 11. test_event finishes and since it tracks the faulty pid the result
> should  be 0 events, but we got 90 == FAULTY
> 
> We can solve this by;
> A: using NR_ITER=2
> or
> B: by adding a flag to gen-ust-events to wait before sending the first event
> 1. test_event_tracker starts gen-ust-events
> 2. test_event_tracker waits for gen-ust-events waits for BEFORE_FIRST_PATH
> 3. test_event_track start collecting events (lttng start .)
> 4. test_event_tracker calls "lttng track ... -pid "Faulty PID"
> 5. test_event_track creates BEFORE_FIRST_PATH
> 6. gen_ust_event creates 100 events
> 7. test_event_tracker waits for gen_event_ust to end
> 8. test_event finishes and since it tracked the faulty pid the result will
> be 0 events == OK
> 
> This is in principle how gen-kernel-test-events works (but with different
> arguments)
> I would suggest to use B since that will be bulletproof
> 
> Anders Wallin
> 
> 
> On Wed, Mar 31, 2021 at 11:33 PM Jonathan Rajotte-Julien <
> jonathan.rajotte-jul...@efficios.com> wrote:
> 
> > Hi,
> >
> > On Wed, Mar 31, 2021 at 11:09:42PM +0200, Anders Wallin wrote:
> > > Hi Julian,
> >
> > You can use Jonathan. ;)
> >
> > >
> > > Neither mine "sleep 0.1" or you

Re: [lttng-dev] [PATCH lttng-tools] Fix: test code assumes that child process is schedule to run before parent

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Wed, Mar 31, 2021 at 11:09:42PM +0200, Anders Wallin wrote:
> Hi Julian,

You can use Jonathan. ;)

> 
> Neither mine "sleep 0.1" or your version with "while [! -f "
> are race condition free.

I might be missing something here but as far as I understand the race you are
trying to mitigate is that the test script execute/continue before the 
`backgrounded`
command (background test app) had time to execute, right?

If so at least waiting for the app to create a file is necessary. Now
gen_kernel_test_events does not have this functionality. The PATH_WAIT_FILE is
used to control when the testapp can continue. Hence the script still cannot
know if the app have been scheduled.

Now based on the test case you might need more synchronization for the test
cases.

Note that in the ust cases, the trace_ust_app uses `touch "$BEFORE_LAST_PATH"`
that effectively unblock the app and allows it to perform the last tracepoint
hit and the we `wait` on the background process.

Note: some tests case are a bit clever and uses "trace_"$domain"_app" instead of
calling trace_ust_app directly.

For these tests case it seems that we are only expecting at least a single event
matching the event name under test. Here the last tracepoint hit should satisfy
this criteria.

Am I missing a race?

Cheers


> I suggest that we add an option to gen-ust-events to wait before the first
> event is generated.
> gen_kernel_test_events already have this functionality to wait before the
> first event.
> 
> Something like this
> static struct option long_options[] =
> {
> /* These options set a flag. */
> {"iter", required_argument, 0, 'i'},
> {"wait", required_argument, 0, 'w'},
> {"sync-after-first-event", required_argument, 0, 'a'},
> {"sync-before-last-event", required_argument, 0, 'b'},
> {"sync-before-last-event-touch", required_argument, 0, 'c'},
> {"sync-before-exit", required_argument, 0, 'd'},
> {"sync-before-exit-touch", required_argument, 0, 'e'},
> *+ {"sync-before-first-event", required_argument, 0, 'f'},*
> 
> {0, 0, 0, 0}
> };
> 
> 
> I will create one or more patches for this tomorrow
> 
> Anders Wallin
> 
> 
> On Wed, Mar 31, 2021 at 9:25 PM Jonathan Rajotte-Julien <
> jonathan.rajotte-jul...@efficios.com> wrote:
> 
> > > #
> > > # SPDX-License-Identifier: GPL-2.0-only
> > >
> > > -TEST_DESC="LTTng - Event traker test"
> > > +TEST_DESC="LTTng - Event tracker test"
> > >
> > > CURDIR=$(dirname "$0")/
> > > TESTDIR="$CURDIR/../../.."
> > > @@ -42,6 +42,8 @@ function prepare_ust_app
> > >
> > >   $TESTAPP_BIN -i $NR_ITER -w $NR_USEC_WAIT -a "$AFTER_FIRST_PATH" -b
> > >   "$BEFORE_LAST_PATH" &
> > >   CHILD_PID=$!
> > > + # voluntary context switch to start $TESTAPP_BIN
> > > + sleep 0.1
> >
> > A wait on the $AFTER_FIRST_PATH file would be probably more deterministic
> > than a sleep here.
> >
> >   while [ ! -f "${AFTER_FIRST_PATH}" ]; do
> >   sleep 0.1
> >   done
> >
> > I would also expect something similar for the `prepare_kernel_app`
> > function considering the same race is most probably present and simply not
> > triggered by a chance of luck.
> > Seems like gen-kernel-test-events does not expose the same sync
> > capabilities here, please use gen-ust-events as an example of how it is
> > done.
> >
> > Let us know how your testing goes.
> >
> > Thanks
> >

-- 
Jonathan Rajotte-Julien
EfficiOS
___
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: test code assumes that child process is schedule to run before parent

[Jonathan Rajotte-Julien via lttng-dev]

> #
> # SPDX-License-Identifier: GPL-2.0-only
> 
> -TEST_DESC="LTTng - Event traker test"
> +TEST_DESC="LTTng - Event tracker test"
> 
> CURDIR=$(dirname "$0")/
> TESTDIR="$CURDIR/../../.."
> @@ -42,6 +42,8 @@ function prepare_ust_app
> 
>   $TESTAPP_BIN -i $NR_ITER -w $NR_USEC_WAIT -a "$AFTER_FIRST_PATH" -b
>   "$BEFORE_LAST_PATH" &
>   CHILD_PID=$!
> + # voluntary context switch to start $TESTAPP_BIN
> + sleep 0.1

A wait on the $AFTER_FIRST_PATH file would be probably more deterministic than 
a sleep here.

  while [ ! -f "${AFTER_FIRST_PATH}" ]; do
  sleep 0.1
  done

I would also expect something similar for the `prepare_kernel_app` function 
considering the same race is most probably present and simply not triggered by 
a chance of luck.
Seems like gen-kernel-test-events does not expose the same sync capabilities 
here, please use gen-ust-events as an example of how it is done.

Let us know how your testing goes.

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

Re: [lttng-dev] Can't trace function calls

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Wed, Mar 31, 2021 at 10:51:03AM -0500, Ramesh Errabolu via lttng-dev wrote:
> I am trying to capture the list of functions being called by an app. The
> app relies on a couple of shared libraries (libhsa-runtime64.so and
> libhsakmt.so).

ok.

> 
> My experiments all *FAIL *i.e. there are no log files of the output.

Not sure what you mean here. But let's continue first. 

> The
> link on lttng-ust-cyg-profile does not tell me where I can get them.

Could you share the "link" in question?

> Instrument the build files for the two libraries to allow function tracing
> by the gcc/clang flags -finstrument-functions and run workload as follows
> 
>- Instrument the build files for the two libraries to allow function
>tracing by the gcc/clang flags *-finstrument-functions* and run workload
>as follows

Okai. I expect that you have read this:
https://lttng.org/docs/v2.12/#doc-liblttng-ust-cyg-profile 

and this
https://lttng.org/man/3/lttng-ust-cyg-profile/v2.12/

> I am using LTTng version Ubuntu: LTTng Stable 2.12 PPA
> 
>- apt-get install lttng-tools
>- apt-get install lttng-modules-dkms
>- apt-get install liblttng-ust-dev
> 

Looks good.

> I noticed no kernel modules with substring "ltt" in it.

Okai so this is where we need much more information. 

First of all, what are the lttng commands used for your experiments? (lttng 
create, lttng enable-channel, lttng enable-event...) 
Please provide a sample script of your experiments. 

Second, you are mostly performing userspace tracing here, lttng-modules ( the
kernel tracer) might not even be needed here unless you also want to do kernel
tracing. 

What do you mean by "there are no log files of the output."? LTTng produces
traces encoded in CTF (Common Trace Format) that must be read by a reader
(Babeltrace most of the time).

Cheers

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

Re: [lttng-dev] Question/Issue compilation ARMv7 of LTTng

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Tue, Mar 30, 2021 at 10:29:22PM +, MONTET Julien via lttng-dev wrote:
> Hello the developpers !
> 
> On my side, userspace and kernel event are working for both x86_64 and 32bits 
> on Ubuntu 20.04.
> One of my main goals is to use LTTng on an armv7 target (Raspbian 32 bits).

Ok.

> 
> I am using Docker to create the environment and to compile the image (Debian 
> 9.3).
> During the compilation of RCU, I get :
> #10 5.868 checking whether the C compiler works... no
> #10 5.982 configure: error: in `/tmp/tmp.T2I20x25bo/userspace-rcu-0.12.2':
> #10 5.983 configure: error: C compiler cannot create executables

I would suggest that you have a look in the config.log file and share with us
the complete file, as always use a paste service if possible.

> 
> My question is the following : Can LTTng be used directly on arm ?

It can absolutely be used on arm.

For example see our portbuild testing matrix here:

URCU:
https://ci.lttng.org/job/liburcu_master_portbuild/

LTTng-tools:
https://ci.lttng.org/job/lttng-tools_master_portbuild/ 

> https://lttng.org/docs/v2.10/#doc-instrumenting-32-bit-app-on-64-bit-system
> I read again the tutorial and it seems we always need a 64-bits platform.

On 32bit only platform you are limited to 32bit tracing and all the limitation
related to 32bit, if any is applicable to your use case.

> 
> Find below a part of my Dockerfile (that looks like the tuto):
> # LTTng RCU - 32 bits
> RUN bin/sh -c 'cd $(mktemp -d)' && \
> wget https://lttng.org/files/urcu/userspace-rcu-0.12.2.tar.bz2 && \
> tar -xvf userspace-rcu-0.12.2.tar.bz2 && \
> cd userspace-rcu-0.12.2 && \
> ./configure --libdir=/usr/local/lib32 CFLAGS=-m32 && \
> make && \
> make install && \
> ldconfig
> 
> I tried to run the installation on the docker file of gcc-multilib, 
> build-essential, wget... but it doesn't work.

Our project use standard autotools/make mechanism for cross compilation 
scenarios: 
https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html

I am not aware of any problem at this level but after looking around our CI I
think we do not do a lot of cross compilation. Still I know that yocto and
buildroot use cross-compilation for lttng and its dependencies without any major
modification.

Still, we will wait for the config.log file before putting this in the: not a 
lttng problem.

Cheers

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

Re: [lttng-dev] LTTng 32 bits : Cannot find liburcu-bp 0.11 or newer

[Jonathan Rajotte-Julien via lttng-dev]

Hi Julien,

Yeah, the urcu version is wrong here it should be >= 0.11. We will get that 
fixed.

Thanks

On Mon, Mar 29, 2021 at 01:24:48PM +, MONTET Julien via lttng-dev wrote:
> Oh my bad !
> You just have to choose modify the lines of the tutorial (rcu).
> I chose 
> userspace-rcu-0.12.2.tar.bz2<https://lttng.org/files/urcu/userspace-rcu-0.12.2.tar.bz2>
>  and it installed well.
> 
> De : MONTET Julien
> Envoyé : lundi 29 mars 2021 11:43
> À : lttng-dev@lists.lttng.org 
> Objet : LTTng 32 bits : Cannot find liburcu-bp 0.11 or newer
> 
> Hi everyone,
> 
> I successfully installed and used LTTng on x86 and x64 (kernel event, 
> userspace, and other tools like TraceCompass).
> 
> Now, I am looking for a way to use LTTng on other processors (arm32, ...).
> 
> I tried to follow the tutorial and, to be honest, I am quite not lost on step 
> 2. (libuuid, popt, libxml2)
> https://lttng.org/docs/v2.12/#doc-instrumenting-32-bit-app-on-64-bit-system
> 
> My current issue is on the step 3.
> During the installation (./configure), I have the following error :
> error: Cannot find liburcu-bp 0.11 or newer. Use LDFLAGS=-Ldir to specify its 
> location.
> 
> This file - liburcu - is in /usr/local/lib32 : Ubuntu 
> Pastebin<https://paste.ubuntu.com/p/b67Bxf6cfB/>
> 
> This topic was started a long time ago here :
> https://lists.lttng.org/pipermail/lttng-dev/2013-February/019641.html
> 
> Would you mind helping me ?

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


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

Re: [lttng-dev] Issues on basic LTTng trace userspace (tutorial)

[Jonathan Rajotte-Julien via lttng-dev]

On Wed, Mar 24, 2021 at 06:55:37PM +, MONTET Julien wrote:
> Hi Jonathan,
> 
> You are absolutely right !
> I have two different lttng :   find /usr -name "*liblttng-ust*" Ubuntu 
> Pastebin<https://paste.ubuntu.com/p/NVtXPhj4fW/>

Glad to know that we are making progress.

> 
> According to you, what would be the best solution to solve this issue ?
> I have indeed a folder named lttng-ust where I have made the (wrong) 
> configure / make.

Go into the lttng folder and do:
  sudo make uninstall
  sudo ldconfig

> 
> 
> I tried to (temporary) remove all the libttng* /usr/local/lib/, but I face 
> this problem :

That should works also.

> /usr/bin/ld: hello-tp.o: in function `__lttng_events_init__hello_world':
> hello-tp.c:(.text+0xe56): undefined reference to `lttng_ust_probe_register'
> /usr/bin/ld: hello-tp.o: in function `__lttng_events_exit__hello_world':
> hello-tp.c:(.text+0xeb2): undefined reference to `lttng_ust_probe_unregister'
> collect2: error: ld returned 1 exit status

Did you remove the -L/usr/local/bin flag? There should be no reason to keep it
at this point.

> 
> In the worst case scenario I am able to get my last clean snapchot.

That is also a good bet :).

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

Re: [lttng-dev] Issues on basic LTTng trace userspace (tutorial)

[Jonathan Rajotte-Julien via lttng-dev]

Hi Julien,

> TBH nothing points toward a problem here. I would need to spawn a 20.04 to 
> check
> if something is broken, I might have time later today.

Finally I had a Vagrant definition file laying around for the stable-2.12 ppa
that let me bring up a vm easily. All seems fine.

How lttng is installed:

  add-apt-repository ppa:lttng/stable-2.12 -y
  apt-get update
  apt-get install -y lttng-tools lttng-modules-dkms babeltrace2 liblttng-ust-dev

>From there all the steps for building the userspace application works without
ANY modifications.

The app is able to connect itself to the global sessiond: 
https://paste.ubuntu.com/p/QnfqbtgpFF/

Note that no local sessiond is present hence why the app does not communicate
with one.

Note that the user I am using here (vagrant) is not part of the "tracing" group
hence the user cannot interact with the global sessiond.

Such scenario return the following:

  vagrant@ubuntu2004:~$ lttng list -u
  Error: Unable to list UST events: No session daemon is available

Now let's start a lttng-sessiond for the user and restart our app (note that
this is not required for day to day tracing since a running app will connect
itself and only for debugging purpose):

 lttng-sessiond -b
 LTTNG_UST_DEBUG=1 ./hello

Yielding: https://paste.ubuntu.com/p/MsnHt94FXZ/

Now the app is connected to both sessiond.

Now the user can list the event against the local lttng-sessiond:

  vagrant@ubuntu2004:~$ lttng list -u
  UST events:
  -
  
  PID: 15429 - Name: ./hello
lttng_ust_tracelog:TRACE_DEBUG (loglevel: TRACE_DEBUG (14)) (type: 
tracepoint)
lttng_ust_tracelog:TRACE_DEBUG_LINE (loglevel: TRACE_DEBUG_LINE (13)) 
(type: tracepoint)


So based on this I would say that either we are not given the full picture of
what is going on or there is a step you are missing. One explication would be
that you end up linking against a older lttng-ust without knowing it.

Please run this an provide the output via a paste service:

   find /usr -name "*liblttng-ust*"

For example on my VM: https://paste.ubuntu.com/p/Tjxn3V7g5j/

Cheers

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

Re: [lttng-dev] Issues on basic LTTng trace userspace (tutorial)

[Jonathan Rajotte-Julien via lttng-dev]

On Wed, Mar 24, 2021 at 03:53:14PM +, MONTET Julien wrote:
> Hi Jonathan,
> 
> After having written 'sudo systemctl stop lttng-sessiond.service', the 
> command 'sudo lttng-sessiond -vvv > /tmp/lttng-sessiond.log 2>&1' gives me 
> nothing.


The log should be in /tmp/lttng-sessiond.log.

> 
> ls -la /var/run/lttng/ : Ubuntu 
> Pastebin<https://paste.ubuntu.com/p/gjbqKkCrZK/>
> groups : Ubuntu Pastebin<https://paste.ubuntu.com/p/pjVFHk7kFZ/>
> lttng-sessiond -vvv > /tmp/lttng-sessiond-local.log 2>&1 : nothing
> /tmp/lttng-sessiond-local.log : Ubuntu 
> Pastebin<https://paste.ubuntu.com/p/bj38FhhVpc/>

Based on the log there is a sessiond already running... anyway this give us the
info we need to know for what socket is made available:

application socket path:   /home/montetju/.lttng/lttng-ust-sock-8
wait shm path: /lttng-ust-wait-8-1000

Could you share the content of:

   ls -la /dev/shm


TBH nothing points toward a problem here. I would need to spawn a 20.04 to check
if something is broken, I might have time later today.

Cheers

> 
> The issue persist with the 'lttng list' command.
> 
> Best regards,
> 
> Sorry it was indeed :
> The command lines entered to compile are quite the same, I just had to modify 
> :
> > this : gcc -o hello hello.o hello-tp.o -llttng-ust -ldl
> > to this : gcc -o hello hello.o hello-tp.o -L/usr/local/lib -llttng-ust -ldl
> (I just wanted to focus the importance of  -L/usr/local/lib)
> 
> 
> De : Jonathan Rajotte-Julien 
> Envoyé : mercredi 24 mars 2021 16:32
> À : MONTET Julien 
> Cc : lttng-dev 
> Objet : Re: [lttng-dev] Issues on basic LTTng trace userspace (tutorial)
> 
> Hi Julien,
> 
> Please always keep the mailing list in CC.
> 
> > I am running 'lttng list --userspace' with the application running in 
> > another terminal (like the tutorial, and also with a while that loop on 
> > tracepoint(...).
> 
> ok.
> 
> >
> > You can find here the Ubuntu paste : Ubuntu 
> > Pastebin<https://paste.ubuntu.com/p/bWw25kmSTq/>
> 
> Based on this, it seems like lttng-ust is unable to find the socket for a 
> sessiond either
> locally (for your user) [1] or a global one (root lttng-sessiond) [2].
> 
> [1] 43:  libust[207688/207690]: Info: sessiond not accepting connections to 
> local apps socket (in ust_listener_thread() at lttng-ust-comm.c:1822)
> [2] 45:  libust[207688/207689]: Info: sessiond not accepting connections to 
> global apps socket (in ust_listener_thread() at lttng-ust-comm.c:1822)
> 
> Since you installed via the PPA, a systemd service control service is 
> installed
> that control a global (root) lttng-sessiond.
> 
> First let's stop it.
>sudo systemctl stop lttng-sessiond.service
> 
> Then in a console, again use a paste service to share the content of 
> /tmp/lttng-sessiond.log with us
> 
>sudo lttng-sessiond -vvv > /tmp/lttng-sessiond.log 2>&1
> 
> In another console, while the lttng-sessiond process is running, please have 
> a look at the /var/run/lttng directory:
> 
>  ls -la /var/run/lttng/
> 
> Again use a paste service to share this with us.
> 
> Also can you provide the output of the following while using the user you are
> normally using to play with lttng:
> 
>  groups
> 
> You can also try to spawn a local lttng-sessiond for the user.
>   Note that a global and many local lttng-sessiond can coexist but for the 
> sake of debugging
>   we will only have one of each at a time.
> 
> Kill the root lttng-sessiond we started earlier and start a local one:
> 
>  lttng-sessiond -vvv > /tmp/lttng-sessiond-local.log 2>&1
> 
>  Note the absence of `sudo` here.
> 
> Again please share the content of /tmp/lttng-sessiond-local.log via a paste
> service.
> 
> From there you can retry your experiment with the `lttng list` command.
> 
> Cheers
> 
> 
> > The command lines entered to compile are quite the same, I just had to 
> > modify :
> > this : gcc -o hello hello.o hello-tp.o
> > to this : gcc -o hello hello.o hello-tp.o -L/usr/local/lib -llttng-ust -ldl
> 
> As per the doc [3]:
> gcc -o hello hello.o hello-tp.o -llttng-ust -ldl
> 
> [3] https://lttng.org/docs/v2.12/#doc-tracing-your-own-user-application 
> Bullet point #6
> 
> Cheers

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

Re: [lttng-dev] Issues on basic LTTng trace userspace (tutorial)

[Jonathan Rajotte-Julien via lttng-dev]

Hi Julien,

Please always keep the mailing list in CC.

> I am running 'lttng list --userspace' with the application running in another 
> terminal (like the tutorial, and also with a while that loop on 
> tracepoint(...).

ok.

> 
> You can find here the Ubuntu paste : Ubuntu 
> Pastebin

Based on this, it seems like lttng-ust is unable to find the socket for a 
sessiond either
locally (for your user) [1] or a global one (root lttng-sessiond) [2].

[1] 43:  libust[207688/207690]: Info: sessiond not accepting connections to 
local apps socket (in ust_listener_thread() at lttng-ust-comm.c:1822)
[2] 45:  libust[207688/207689]: Info: sessiond not accepting connections to 
global apps socket (in ust_listener_thread() at lttng-ust-comm.c:1822)

Since you installed via the PPA, a systemd service control service is installed
that control a global (root) lttng-sessiond.

First let's stop it.
   sudo systemctl stop lttng-sessiond.service

Then in a console, again use a paste service to share the content of 
/tmp/lttng-sessiond.log with us

   sudo lttng-sessiond -vvv > /tmp/lttng-sessiond.log 2>&1

In another console, while the lttng-sessiond process is running, please have a 
look at the /var/run/lttng directory:

 ls -la /var/run/lttng/

Again use a paste service to share this with us.

Also can you provide the output of the following while using the user you are
normally using to play with lttng:

 groups

You can also try to spawn a local lttng-sessiond for the user.
  Note that a global and many local lttng-sessiond can coexist but for the sake 
of debugging
  we will only have one of each at a time. 

Kill the root lttng-sessiond we started earlier and start a local one:

 lttng-sessiond -vvv > /tmp/lttng-sessiond-local.log 2>&1 

 Note the absence of `sudo` here.

Again please share the content of /tmp/lttng-sessiond-local.log via a paste
service.

>From there you can retry your experiment with the `lttng list` command.

Cheers


> The command lines entered to compile are quite the same, I just had to modify 
> :
> this : gcc -o hello hello.o hello-tp.o
> to this : gcc -o hello hello.o hello-tp.o -L/usr/local/lib -llttng-ust -ldl

As per the doc [3]:
gcc -o hello hello.o hello-tp.o -llttng-ust -ldl

[3] https://lttng.org/docs/v2.12/#doc-tracing-your-own-user-application Bullet 
point #6

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

Re: [lttng-dev] Issues on basic LTTng trace userspace (tutorial)

[Jonathan Rajotte-Julien via lttng-dev]

Hi Julien,

On Wed, Mar 24, 2021 at 11:29:04AM +, MONTET Julien via lttng-dev wrote:
> Hello the LTTng team !
> 
> I would like, at first, to thank you for your projet and your impressive work 
> !
> 
> For the past few days I have been trying to learn how to use lttng (v2.12).
> 
> I followed the installation on your website for an Ubuntu 20.04.
> [cid:c663399f-0584-43d3-90c5-3aa277ee7020]

Good. So just to validate you used the stable 2.12 PPA as described in this
section [1] ?.

[1] https://lttng.org/docs/v2.12/#doc-ubuntu-ppa

> 
> The steps to get the trace of a Linux kernel and the babel trace are great !
> 
> However, I am stuck for the 'Trace a user application' : 
> https://lttng.org/docs/v2.12/#doc-tracing-your-own-user-application
> Compilation steps are ok, it launches without error but lttng list 
> --userspace  gives me nothing.

When you perform the `lttng list --userspace` command is your user application
running? If not, `lttng list --userspace` can only list running application.

If your application is running, we will need to go a bit further and have some
debug info.

You can at least check if lttng-ust, on the application side, can successfully
communicate with the lttng-sessiond process. For this, you will have to use
LTTNG_UST_DEBUG.

Here's how to us it:

 1) Make sure a lttng-sessiond is present,
 2) Start your application like so:  LTTNG_UST_DEBUG=1 your_application,
 3) Debug messages from lttng-ust should appear on the stderr.

Please use a paste service [2] to share this information with us. 

[2] https://paste.ubuntu.com/

Au plaisir!

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

Re: [lttng-dev] Reg: LTTNG Support for arm64 based k3-am654 board

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Wed, Mar 17, 2021 at 01:43:59PM +, Vadivel, Arulpandiyan via lttng-dev 
wrote:
> Hi Team,
> 
> We are working on the Texas Instrument's K3-am654 board(ARM64 based), on
> 4.19.165-cip41 RT and Non-RT kernel. We would like to have the lttng
> support on the board. Hence I have added below configurations.  With these
> configurations enabled I am not able to access the console itself and
> kernel stuck at Starting kernel itself as below.  Further we have added
> earlycon to debug the early console.  Bootargs given below. With these
> earlycon option also we are still stuck at  Starting kernel  itself.
> 
> 
> Could you please help me to understand below queries,
> 
>   *Do we have the support of lttng for TI's K3-am654 board?

EfficiOS inc. offers commercial support for such specific cases. Please
contact us at sa...@efficios.com.

We do perform an overall effort for arm32/64 support but if you need support for
a specific board, commercial support is the way to go.

>   *Or did we miss something in the kernel?

I would say that you might have bitten off more than you can chew.

First, remove lttng from the equation. Make sure you get back to a working
state (kernel is booting).

Then add the options that lttng-modules depends on but do not touch at lttng 
just
yet.

Based on your previous message that should look like this, please validate
against the README of the version you are trying to use [1]:
  CONFIG_KPROBES=y
  CONFIG_PERF_EVENTS=y
  CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
  CONFIG_EVENT_TRACING=y
  CONFIG_KRETPROBES=y
  CONFIG_KALLSYMS=y
  CONFIG_KALLSYMS_ALL=y
  CONFIG_HIGH_RES_TIMERS=y
  CONFIG_TRACEPOINTS=y
  CONFIG_FTRACE=y
  CONFIG_FUNCTION_TRACER=y

[1] For example for 2.12: 
https://github.com/lttng/lttng-modules/blob/stable-2.12/README.md

Then you make sure that you can boot your kernel. Let me reiterate that at this
point there is NO presence of lttng at any build steps of the process.

Then, when you have a booting kernel with the necessary dependency, you can
build lttng-modules, as modules, against your kernel tree [3], tarball them, 
and deploy them
on the target (under /lib/modules/$(uname -r)/). Then you try to load them
using lttng-sessiond in verbose mode and even try to trace some kernel stuff. 

[2] Note that since you are probably in a cross compilation scenario this will
be a bit more complex then simply following
https://github.com/lttng/lttng-modules/blob/stable-2.12/README.md#building

When this works, you can stop there or if you want you can bake-in the modules
directly into the kernel compilation steps following this [3].

[3] Again for 2.12: 
https://github.com/lttng/lttng-modules/blob/stable-2.12/README.md#kernel-built-in-support

And as always if you succeed or fail (and that it is related to lttng...),
please come back and tell us what happened on the mailing list so that others in
a similar situation might find some piece of valuable information.

Cheers


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

Re: [lttng-dev] 回复: 回复: help modpost: "__bad_cmpxchg"

[Jonathan Rajotte-Julien via lttng-dev]

Hi Quiang,

Please test the attached patch.

Cheers

On Sat, Jan 09, 2021 at 05:40:48AM +, Zhang, Qiang wrote:
> 
> 
> ____
> 发件人: Jonathan Rajotte-Julien 
> 发送时间: 2021年1月8日 0:54
> 收件人: Zhang, Qiang
> 抄送: lttng-dev
> 主题: Re: 回复: help modpost: "__bad_cmpxchg"
> 
> [Please note this e-mail is from an EXTERNAL e-mail address]
> 
> >Hi,
> >
> >Note
> >  The initial email was sent to the "owner" of the mailing list. Please
> >  *always* send email to the mailing list directly: 
> > lttng->d...@lists.lttng.org .
> > Otherwise we will not be interested in helping you in the future.
> >
> >Sorry forgot to ask you the following.
> >
> >What is the arm CPU you are compiling against? The more details the >more we 
> >can
> >help here.
> >
> >Please provide the .config file for the kernel (via pastebin please) and >the
>  
>  Hello
> 
>  Attached is the kernel configuration file
>  and compiler configuration file.
> 
>  bsp is xilinx-zynq (arm32, armv7),  v5.10 kernel have delete 
>  'CONFIG_OPTIMIZE_INLINING'  config option. 
> 
>  Cheers
> 
> >compiler used. Mathieu Desnoyers (CompuDJ) might have a lead >regarding 
> >cmpxchg
> >and __bad_cmpxchg linker error trick used by the implementation and >the
> >optimized inlining config option (CONFIG_OPTIMIZE_INLINING).
> >
> >These should help us validate this lead.
> 
> >
> >Cheers
> >
> >On Thu, Jan 07, 2021 at 01:20:54AM +, Zhang, Qiang wrote:
> >
> >
> > 
> > 发件人: Jonathan Rajotte-Julien 
> > 发送时间: 2021年1月6日 23:03
> > 收件人: Zhang, Qiang
> > 抄送: lttng-dev-ow...@lists.lttng.org
> > 主题: Re: help modpost: "__bad_cmpxchg"
> >
> > [Please note this e-mail is from an EXTERNAL e-mail address]
> >
> > >Hi,
> > >
> > >What the kernel version are you compiling against?
> >
> >
> >kernel version 5.10.2
> >lttng-modules master branch commit :
> >61e631e93e512b636ea6d52796bcce1c485a551b
> >
> > Cheers
> >
> > >
> > >Cheers
> > >
> > >On Wed, Jan 06, 2021 at 05:20:06AM +, Zhang, Qiang wrote:
> > >
> > >
> > > The following error occurred when I compiled lttng modules under armv7 
> > > architecture
> > >
> > > ERROR: modpost: "__bad_cmpxchg" 
> > > [/buildarea1/OnDemand_CI_Build_World/build_dir/12251727-build_world/xilinx-zynq-standard-std-OE/build/tmp-glibc/work/xilinx_zynq-wrs-linux-gnueabi/lttng-modules/2.12.3+gitAUTOINC+61e631e93e-r0/git/src/lttng-counter-client-percpu-64-modular.ko]
> > >  undefined!
> > >
> > > ERROR: modpost: "__bad_cmpxchg" 
> > > [/buildarea1/OnDemand_CI_Build_World/build_dir/12251727-build_world/xilinx-zynq-standard-std-OE/build/tmp-glibc/work/xilinx_zynq-wrs-linux-gnueabi/lttng-modules/2.12.3+gitAUTOINC+61e631e93e-r0/git/src/lttng-counter-client-percpu-32-modular.ko]
> > >  undefined!
> > >
> > > I find  under the condition of
> > >
> > > COUNTER_SIZE_32_BIT,  cmpxchg_local  function trigger error in 
> > > counter-api.h file.
> > >
> > > is cmpxchg_local is support in amv7?
> >
> > --
> > Jonathan Rajotte-Julien
> > EfficiOS
> 
> --
> Jonathan Rajotte-Julien
> EfficiOS


> ./arm-wrs-linux-gnueabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=./arm-wrs-linux-gnueabi-gcc
> COLLECT_LTO_WRAPPER=/buildarea1/qzhang2/jira/LINCD-3904/build/tmp-glibc/work/armv7at2hf-neon-wrs-linux-gnueabi/libgcc/10.2.0-r0/recipe-sysroot-native/usr/bin/arm-wrs-linux-gnueabi/../../libexec/arm-wrs-linux-gnueabi/gcc/arm-wrs-linux-gnueabi/10.2.0/lto-wrapper
> Target: arm-wrs-linux-gnueabi
> Configured with: 
> ../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/configure 
> --build=x86_64-linux --host=x86_64-linux --target=arm-wrs-linux-gnueabi 
> --prefix=/host-native/usr --exec_prefix=/host-native/usr 
> --bindir=/host-native/usr/bin/arm-wrs-linux-gnueabi 
> --sbindir=/host-native/usr/bin/arm-wrs-linux-gnueabi 
> --libexecdir=/host-native/usr/libexec/arm-wrs-linux-gnueabi 
> --datadir=/host-native/usr/share --sysconfdir=/host-native/etc 
> --sharedstatedir=/host-native/com --localstatedir=/host-native/var 
> --libdir=/host-native/usr/lib/arm-wrs-linux-gnueabi 
> --includedir=/host-native/usr/include 
> --oldincludedir=/host-native/usr/include 
> --infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man 
> --disable-silent-rules --disable-dependency-tra

Re: [lttng-dev] 回复: help modpost: "__bad_cmpxchg"

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

Note
  The initial email was sent to the "owner" of the mailing list. Please
  *always* send email to the mailing list directly: lttng-dev@lists.lttng.org .
  Otherwise we will not be interested in helping you in the future.
  
Sorry forgot to ask you the following.

What is the arm CPU you are compiling against? The more details the more we can
help here.

Please provide the .config file for the kernel (via pastebin please) and the
compiler used. Mathieu Desnoyers (CompuDJ) might have a lead regarding cmpxchg
and __bad_cmpxchg linker error trick used by the implementation and the
optimized inlining config option (CONFIG_OPTIMIZE_INLINING).

These should help us validate this lead.

Cheers

On Thu, Jan 07, 2021 at 01:20:54AM +, Zhang, Qiang wrote:
> 
> 
> ____
> 发件人: Jonathan Rajotte-Julien 
> 发送时间: 2021年1月6日 23:03
> 收件人: Zhang, Qiang
> 抄送: lttng-dev-ow...@lists.lttng.org
> 主题: Re: help modpost: "__bad_cmpxchg"
> 
> [Please note this e-mail is from an EXTERNAL e-mail address]
> 
> >Hi,
> >
> >What the kernel version are you compiling against?
> 
> 
>kernel version 5.10.2
>lttng-modules master branch commit :
>61e631e93e512b636ea6d52796bcce1c485a551b
> 
> Cheers
>
> >
> >Cheers
> >
> >On Wed, Jan 06, 2021 at 05:20:06AM +, Zhang, Qiang wrote:
> >
> >
> > The following error occurred when I compiled lttng modules under armv7 
> > architecture
> >
> > ERROR: modpost: "__bad_cmpxchg" 
> > [/buildarea1/OnDemand_CI_Build_World/build_dir/12251727-build_world/xilinx-zynq-standard-std-OE/build/tmp-glibc/work/xilinx_zynq-wrs-linux-gnueabi/lttng-modules/2.12.3+gitAUTOINC+61e631e93e-r0/git/src/lttng-counter-client-percpu-64-modular.ko]
> >  undefined!
> >
> > ERROR: modpost: "__bad_cmpxchg" 
> > [/buildarea1/OnDemand_CI_Build_World/build_dir/12251727-build_world/xilinx-zynq-standard-std-OE/build/tmp-glibc/work/xilinx_zynq-wrs-linux-gnueabi/lttng-modules/2.12.3+gitAUTOINC+61e631e93e-r0/git/src/lttng-counter-client-percpu-32-modular.ko]
> >  undefined!
> >
> > I find  under the condition of
> >
> > COUNTER_SIZE_32_BIT,  cmpxchg_local  function trigger error in 
> > counter-api.h file.
> >
> > is cmpxchg_local is support in amv7?
> 
> --
> Jonathan Rajotte-Julien
> EfficiOS

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

Re: [lttng-dev] 回复： Enamebling namespace contexts

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

> The version of my lttng is: lttng (LTTng Trace Control) 2.10.7 - KeKriek.

Please upgrade to lttng 2.12.x. Container awareness was added in the 2.12 
release
cycle.

Cheers

> Thanks,
> Serica
> 
> 
> --原始邮件--
> 发件人:  
>   "Mathieu Desnoyers" 
>
>  发送时间:2020年12月29日(星期二) 中午11:58
> 收件人:"Serica" 抄送:"lttng-dev" 主题:Re: [lttng-dev] Enamebling namespace contexts
> 
> 
> 
> - On Dec 23, 2020, at 9:55 PM, lttng-dev  wrote:
> 
> Hi,
> 
> ThI found that lttng is working on container awareness in this slides: 
> https://archive.fosdem.org/2019/schedule/event/containers_lttng/attachments/slides/3419/export/events/attachments/containers_lttng/slides/3419/lttng_containers_fosdem19.pdf
> 
> On page #13, there is a command: lttng add-context -k -t procname -t 
> pid -t vpid -t tid -t vtid -t pid_ns, where pid_ns and other namespace 
> identifiers are very useful for tracing containers. However, it seems like 
> that lttng of current version doesn't support adding context pid_ns(Error: 
> Unknown context type pid_ns). Do you know how to enable these features?
> 
> What version of LTTng do you use (output of "lttng --version"), and what is 
> the output of "lttng add-context --list" ?
> 
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Some confusion about cpu usage of the lttng-consumerd process

[Jonathan Rajotte-Julien via lttng-dev]

> From: "熊毓华" 
> To: "Jonathan Rajotte-Julien" ,
> "lttng-dev" 
> Sent: Friday, November 27, 2020 10:32:07 AM
> Subject: Re: Re: [lttng-dev] Some confusion about cpu usage of the
> lttng-consumerd process

> Hi，Dear.

Side note, you can remove the "Dear" here. ;) 

> The test script was used to generate some common fileIO,netIO events.

Please provide a complete code repository if possible. So that we can at least 
have a baseline for reproduction. 

> On all servers, the monitoring strategy I set up when I start lttng is the 
> same,
> monitoring all fileIO, netIO and some related system calls.
> The following table records the amount of events generated by the test script
> per minute, and one babeltrace record represents one event.

For some reason the image does not load here. Please provide a text based 
alternative for this figure. 

> The unit of the number is every ten thousand events per minute. And the number
> were read out after parsing by babeltrace.
> In addition, the server1 is 1core4G, server2 is 2core8G, server3 is 4core16G,
> server4 and server5 are 8core16G.

> It can be seen that the average amount of data generated per minute on all
> servers is roughly the same.However, the CPU usage of the lttng-consumerd
> process behave differently on server4 and server5, as I mentioned in my last
> email.

> In addition, the usage of cpu is recorded using the "top" command.

> My test concluded that, while the same number of events collected,
> lttng-consumerd process need to consume more cpu on the 8-core server.

> I want to know why is this and what else information do you need?

Well we also want to know why! You will understand that albeit we develop lttng 
we do not always have a quick and easy answer to all problems. Performance 
related problem are always tricky. 
And we also have to keep in mind that we do not necessarily optimize for 
low-cpu usage on the lttng-consumerd side. 

We have to take a look at what "work" scale with the number of CPU on the 
lttng-consumerd side. One such thing is the live timer which is fired on an 
interval (default is 1s (100us)). 

You could test this hypothesis by streaming the trace instead of using the live 
feature. 

lttng create --set-url  

Cheers 

> Looking forward to your reply.
> thanks,
> yuhua.
> > -原始邮件-
> > 发件人: "Jonathan Rajotte-Julien" < jonathan.rajotte-jul...@efficios.com >
> > 发送时间: [ callto:2020-11-27 22 | 2020-11-27 22 ] :05:48 (星期五)
> > 收件人: "熊毓华" < xiongyu...@zju.edu.cn >
> > 抄送: lttng-dev@lists.lttng.org
>> 主题: Re: [lttng-dev] Some confusion about cpu usage of the lttng-consumerd
> > process

> > Hi,

> > On Fri, Nov 27 , 2020 at 02:39:28PM +0800, 熊毓华 via lttng-dev wrote:
> > > Hi，dear.

>> > I have been using lttng to monitor my server these days，but I found 
>> > something
> > > interesting.

> > > The cpu usage of lttng varies with the number of cpu cores of the server.

> > Which is a bit expected since more CPU means more "data" source from the 
> > point
> > of view of lttng hence more "work" overall.


>> > On the server, I create a tracing session in live mode, using "lttng create
> > > my-session --live".

>> > Then,I Start the babeltrace2 and configure it to connect to the relay
> > > daemon,using "--input-format=lttng-live" mode.

> > > I used 5 cloud servers，1core4G 2core8G 4core16G 8core16G 8core16G.

> > > And,the same test script was executed above to provide the same workload.

> > We would need the test script to have some context here of the workload.


> > > As we all know,lttng has 5 processes,

> > > 1.lttng-runas --daemonize

>> > 2.lttng-runas -k --consumerd-cmd-sock /var/run/lttng/kconsumerd/command
> > > --consumerd-err-sock /var/run/lttng/kconsumerd/error --group tracing

> > Based on this you are performing kernel tracing.


> > > 3.lttng-sessiond --daemonize

> > > 4.lttng-relayd -L tcp://localhost:5344

>> > 5.lttng-consumerd -k --consumerd-cmd-sock /var/run/lttng/kconsumerd/command
> > > --consumerd-err-sock /var/run/lttng/kconsumerd/error --group tracing


>> > The CPU usage of the first four processes is below 2% on the 5 servers,but 
>> > the
> > > lttng-consumerd process is different.

>> > On 1-core、2-core、4-core servers，the CPU usage of the lttng-consumerd 
>> > process is
> > > below 2%.

> > How is the cpu usage measured here?


>> > But on two 8-core machines, the cpu usage of the lttng-consumerd process 
>> > reached
> > > 10

Re: [lttng-dev] Some confusion about cpu usage of the lttng-consumerd process

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Fri, Nov 27, 2020 at 02:39:28PM +0800, 熊毓华 via lttng-dev wrote:
> Hi，dear.
> 
> I have been using lttng to monitor my server these days，but I found something 
> interesting.
> 
> The cpu usage of lttng varies with the number of cpu cores of the server.

Which is a bit expected since more CPU means more "data" source from the point
of view of lttng hence more "work" overall.

> 
> On the server, I create a tracing session in live mode, using "lttng create 
> my-session --live". 
> 
> Then,I Start the babeltrace2 and configure it to connect to the relay 
> daemon,using "--input-format=lttng-live" mode.
> 
> I used 5 cloud servers，1core4G 2core8G 4core16G 8core16G 8core16G.
> 
> And,the same test script was executed above to provide the same workload.

We would need the test script to have some context here of the workload.

> 
> As we all know,lttng has 5 processes,
> 
> 1.lttng-runas--daemonize
> 
> 2.lttng-runas  -k --consumerd-cmd-sock /var/run/lttng/kconsumerd/command 
> --consumerd-err-sock /var/run/lttng/kconsumerd/error --group tracing

Based on this you are performing kernel tracing.

> 
> 3.lttng-sessiond --daemonize
> 
> 4.lttng-relayd -L tcp://localhost:5344
> 
> 5.lttng-consumerd  -k --consumerd-cmd-sock /var/run/lttng/kconsumerd/command 
> --consumerd-err-sock /var/run/lttng/kconsumerd/error --group tracing
> 
> 
> The CPU usage of the first four processes is below 2% on the 5 servers,but 
> the lttng-consumerd process is different.
> 
> On 1-core、2-core、4-core servers，the CPU usage of the lttng-consumerd process 
> is below 2%.

How is the cpu usage measured here?

> 
> But on two 8-core machines, the cpu usage of the lttng-consumerd process 
> reached 10% or more.

Consumerd is responsible of "fetching" data from the ring buffers and "saving"
it either locally (trace on disk) or remotely (streaming/live session). CPU 
usage
should be a bit correlated with the event production rate. Did you have a look 
at the
number of events generated for a similar interval?

> And,the cpu usage of the babeltrace process is not much different,just the 
> cpu usage of the lttng-consumerd process varies with the number of cpu cores 
> of the server.
> 
> Why it is like this？How should this phenomenon be analyzed?
> 
> Looking forward to your reply.
> 
> thanks,
> yuhua
> 
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


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

Re: [lttng-dev] [EXTERNAL] Re: lttng 2.12 install

[Jonathan Rajotte-Julien via lttng-dev]

On Tue, Nov 24, 2020 at 09:02:41PM +, Weber, John wrote:
> Ok, it I get what you're saying then I am modifying make on the command line 
> while running make?

Yeah.

> Still the same problem. I don't think it is using the gcc I am specifying as 
> it continues to look in: /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/

This is normal since you are compiling the modules against that source tree.

> And I suspect it is still seeing the OS version of gcc (4.8.5) instead of the 
> 6.3.1 provided by devtoolset-6.

At this point, I would take a look at the actual package installed that provide 
gcc
4.8.5 and have a look at what is available from centos/redhjat and also maybe 
ping
a centos mailing list. You can CC me on that email if you feel like
it just in case it turn out the problem is on our side.

> Do you have some pixy dust??

Sadly, no. Others might have some left...

> 
> 
> John Weber
> Ball Aerospace
> ITS ND System Administrator 
> 10 Longs Peak Dr., Broomfield, CO 80021
> C: 303-807-3608   P: 303-234-2103
> E: jweb...@ball.com
>  
>  
> 
>  
> 
>  
> 
> -Original Message-
> From: Jonathan Rajotte-Julien  
> Sent: Tuesday, November 24, 2020 1:22 PM
> To: Weber, John 
> Cc: 'lttng-dev@lists.lttng.org' 
> Subject: Re: [EXTERNAL] Re: [lttng-dev] lttng 2.12 install
> 
> Hi John,
> 
> AFAIK, you should be able to do so using something similar to the following:
> 
>   make CC="your_compiler" HOSTCC="your_compiler" ...
> 
> Cheers
> 
> 
> On Tue, Nov 24, 2020 at 07:22:10PM +, Weber, John wrote:
> > Hi, thanks for your reply. So, on my system there are 2 gcc's. one 
> > installed by the OS and the other by installation of devtooset-6. Upon 
> > checking the versions of both I have 4.8.5 installed by OS in /usr/bin 
> > the other one from devtoolset is 6.3.1. Your reference to check 
> > /proc/version shows that it sees 4.8.5. how can I manipulate the 
> > install to use the gcc from /opt/rh/devtoolset-6/root/bin/gcc (which 
> > is 6.3.1)
> > 
> > 
> > John Weber
> > Ball Aerospace
> > ITS ND System Administrator
> > 10 Longs Peak Dr., Broomfield, CO 80021
> > C: 303-807-3608   P: 303-234-2103
> > E: jweb...@ball.com
> >  
> >  
> > 
> >  
> > 
> >  
> > 
> > -Original Message-
> > From: Jonathan Rajotte-Julien 
> > Sent: Friday, November 20, 2020 11:48 AM
> > To: Weber, John 
> > Cc: 'lttng-dev@lists.lttng.org' 
> > Subject: [EXTERNAL] Re: [lttng-dev] lttng 2.12 install
> > 
> > Hi John,
> > 
> > This does not seems to be directly related to the lttng-modules project.
> > 
> > This errors seems to arise because of the compiler you are using to compile 
> > lttng-modules (kernel modules). The RETPOLINE check is part of the kernel 
> > build system, not directly lttng-modules.
> > 
> > I would recommend that you take a look at the /proc/version file and the 
> > compiler that was used to compile your kernel. 
> > 
> > Also note that EfficiOS [1] provide commercial support if you ever need 
> > more in-depth support. 
> > 
> > Cheers
> > 
> > [1] 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.efficios.com_
> > contact_=DwIBAg=jF7FvYH6t0RX1HrEjVCgHQ=t_BRyMysL9XIchJvkrT9wQ=
> > EB0u_nTE1tUx4ZXA7ENPxCS2zGFrbf0ZpfI5DiP051o=JumKvFuRjeKw-8NQkpWd1nN8
> > ZOHAo-JMUMiqWc2Oq9o=
> > 
> > On Fri, Nov 20, 2020 at 05:43:00PM +, Weber, John via lttng-dev wrote:
> > > Hi, I have a centos 7.8 workstation that I'm trying to install 
> > > lttng-modules & lttng-tools from source. Based on your install 
> > > instructions I'm working on installing the modules part first and its 
> > > failing. I am getting the error:
> > > Make entering directory /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64
> > > Arch/x86/Makefile:166 *** CONFIG_RETPOLINE=y, but not supported by 
> > > the compiler. Compiler update recommended... stop
> > > Make: modules error 2
> > > 
> > > Help, how can I get this program to install? Im stuck. Also, my work 
> > > environment is classified so there is no access to internet from high 
> > > side.
> > > 
> > > 
> > > John Weber
> > > Ball Aerospace
> > > ITS ND System Administrator
> > > 10 Longs Peak Dr., Broomfield, CO 80021
> > > C: 303-807-3608   P: 303-234-2103
> > > E: jweb...@ball.com
> 

Re: [lttng-dev] [EXTERNAL] Re: lttng 2.12 install

[Jonathan Rajotte-Julien via lttng-dev]

Hi John,

AFAIK, you should be able to do so using something similar to the following:

  make CC="your_compiler" HOSTCC="your_compiler" ...

Cheers


On Tue, Nov 24, 2020 at 07:22:10PM +, Weber, John wrote:
> Hi, thanks for your reply. So, on my system there are 2 gcc's. one installed 
> by the OS and the other by installation of devtooset-6. Upon checking the 
> versions of both I have 4.8.5 installed by OS in /usr/bin the other one from 
> devtoolset is 6.3.1. Your reference to check /proc/version shows that it sees 
> 4.8.5. how can I manipulate the install to use the gcc from 
> /opt/rh/devtoolset-6/root/bin/gcc (which is 6.3.1)
> 
> 
> John Weber
> Ball Aerospace
> ITS ND System Administrator 
> 10 Longs Peak Dr., Broomfield, CO 80021
> C: 303-807-3608   P: 303-234-2103
> E: jweb...@ball.com
>  
>  
> 
>  
> 
>  
> 
> -Original Message-
> From: Jonathan Rajotte-Julien  
> Sent: Friday, November 20, 2020 11:48 AM
> To: Weber, John 
> Cc: 'lttng-dev@lists.lttng.org' 
> Subject: [EXTERNAL] Re: [lttng-dev] lttng 2.12 install
> 
> Hi John,
> 
> This does not seems to be directly related to the lttng-modules project.
> 
> This errors seems to arise because of the compiler you are using to compile 
> lttng-modules (kernel modules). The RETPOLINE check is part of the kernel 
> build system, not directly lttng-modules.
> 
> I would recommend that you take a look at the /proc/version file and the 
> compiler that was used to compile your kernel. 
> 
> Also note that EfficiOS [1] provide commercial support if you ever need more 
> in-depth support. 
> 
> Cheers
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.efficios.com_contact_=DwIBAg=jF7FvYH6t0RX1HrEjVCgHQ=t_BRyMysL9XIchJvkrT9wQ=EB0u_nTE1tUx4ZXA7ENPxCS2zGFrbf0ZpfI5DiP051o=JumKvFuRjeKw-8NQkpWd1nN8ZOHAo-JMUMiqWc2Oq9o=
>  
> 
> On Fri, Nov 20, 2020 at 05:43:00PM +, Weber, John via lttng-dev wrote:
> > Hi, I have a centos 7.8 workstation that I'm trying to install 
> > lttng-modules & lttng-tools from source. Based on your install instructions 
> > I'm working on installing the modules part first and its failing. I am 
> > getting the error:
> > Make entering directory /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64
> > Arch/x86/Makefile:166 *** CONFIG_RETPOLINE=y, but not supported by the 
> > compiler. Compiler update recommended... stop
> > Make: modules error 2
> > 
> > Help, how can I get this program to install? Im stuck. Also, my work 
> > environment is classified so there is no access to internet from high side.
> > 
> > 
> > John Weber
> > Ball Aerospace
> > ITS ND System Administrator
> > 10 Longs Peak Dr., Broomfield, CO 80021
> > C: 303-807-3608   P: 303-234-2103
> > E: jweb...@ball.com
> > 
> > 
> > [cid:image001.jpg@01D6BF29.AD6C5250]
> > 
> > 
> > [cid:image002.jpg@01D6BF29.AD6C5250]<http://www.ball.com/aerospace>
> > 
> > This message and any enclosures are intended only for the addressee.  
> > Please notify the sender by email if you are not the intended 
> > recipient.  If you are not the intended recipient, you may not use, 
> > copy, disclose, or distribute this message or its contents or 
> > enclosures to any other person and any such actions may be unlawful.  
> > Ball reserves the right to monitor and review all messages and enclosures 
> > sent to or from this email address.
> 
> 
> 
> 
> > _______
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lttng.org_c
> > gi-2Dbin_mailman_listinfo_lttng-2Ddev=DwIBAg=jF7FvYH6t0RX1HrEjVCgH
> > Q=t_BRyMysL9XIchJvkrT9wQ=EB0u_nTE1tUx4ZXA7ENPxCS2zGFrbf0ZpfI5DiP05
> > 1o=tlmdamhJeWU81ADw4gyy0TeCGIhuLXutgPxwQNZsQUk=
> 
> 
> --
> Jonathan Rajotte-Julien
> EfficiOS
> 
> This message and any enclosures are intended only for the addressee.  Please 
> notify the sender by email if you are not the intended recipient.  If you are 
> not the intended recipient, you may not use, copy, disclose, or distribute 
> this 
> message or its contents or enclosures to any other person and any such 
> actions 
> may be unlawful.  Ball reserves the right to monitor and review all messages 
> and enclosures sent to or from this email address.

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

Re: [lttng-dev] lttng 2.12 install

[Jonathan Rajotte-Julien via lttng-dev]

Hi John,

This does not seems to be directly related to the lttng-modules project.

This errors seems to arise because of the compiler you are using to compile
lttng-modules (kernel modules). The RETPOLINE check is part of the kernel build
system, not directly lttng-modules.

I would recommend that you take a look at the /proc/version file and the
compiler that was used to compile your kernel. 

Also note that EfficiOS [1] provide commercial support if you ever need more
in-depth support. 

Cheers

[1] https://www.efficios.com/contact/

On Fri, Nov 20, 2020 at 05:43:00PM +, Weber, John via lttng-dev wrote:
> Hi, I have a centos 7.8 workstation that I'm trying to install lttng-modules 
> & lttng-tools from source. Based on your install instructions I'm working on 
> installing the modules part first and its failing. I am getting the error:
> Make entering directory /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64
> Arch/x86/Makefile:166 *** CONFIG_RETPOLINE=y, but not supported by the 
> compiler. Compiler update recommended... stop
> Make: modules error 2
> 
> Help, how can I get this program to install? Im stuck. Also, my work 
> environment is classified so there is no access to internet from high side.
> 
> 
> John Weber
> Ball Aerospace
> ITS ND System Administrator
> 10 Longs Peak Dr., Broomfield, CO 80021
> C: 303-807-3608   P: 303-234-2103
> E: jweb...@ball.com
> 
> 
> [cid:image001.jpg@01D6BF29.AD6C5250]
> 
> 
> [cid:image002.jpg@01D6BF29.AD6C5250]<http://www.ball.com/aerospace>
> 
> This message and any enclosures are intended only for the addressee.  Please 
> notify the sender by email if you are not the intended recipient.  If you are 
> not the intended recipient, you may not use, copy, disclose, or distribute 
> this 
> message or its contents or enclosures to any other person and any such 
> actions 
> may be unlawful.  Ball reserves the right to monitor and review all messages 
> and enclosures sent to or from this email address.




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


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

Re: [lttng-dev] Help needed: No UST events recorded

[Jonathan Rajotte-Julien via lttng-dev]

Hi Moritz,

From the lttng-sessiond log:

PERROR - 08:04:45.465478146 [575/575]: Failed to open wait shm at 
/lttng-ust-wait-8: Function not implemented (in get_wait_shm() at shm.c:98)
DEBUG1 - 08:04:45.465496345 [575/575]: Failing to get the wait shm fd (in 
get_wait_shm() at shm.c:143)
Error: Failed to notify applications or create the wait shared memory.
Execution continues but there might be problems for already
running applications that wishes to register.

On the app side we see that the app never register:

libust[694/694]: Error: Error opening shm /lttng-ust-wait-8-0 (in 
get_wait_shm() at lttng-ust-comm.c:1241)
libust[694/694]: Warning: Unable to get map shm for local apps. Disabling 
LTTng-UST per-user tracing. (in setup_local_apps() at lttng-ust-comm.c:523)


Does the /dev/shm mount point exist?
Does your kernel support shared memory/tmpfs?

Cheers

On Tue, Aug 04, 2020 at 08:15:08AM +, PFLANZER Moritz wrote:
> Hi Jonathan,
> 
> Apologies that I forgot to mention which version of LTTng I'm using. I didn't 
> build from master but downloaded the latest release archives for LTTng 2.12 
> "(Ta) Meilleure". "lttng --version" reports a corresponding "lttng (LTTng 
> Trace Control) 2.12.1 - (Ta) Meilleure"
> 
> Please find the console log here: https://pastebin.com/PVzqrPvr
> and the lttng-sessiond.log here: https://pastebin.com/g3aXAcQg
> 
> Thanks,
> Moritz
> 
> 
> 
> Moritz Pflanzer
> Software Development Engineer
> 
> [cid:image001.png@01D3BF6E.185110B0]
> 
> Räffelstrasse 28
> 
> 8045 Zürich
> E: 
> moritz.pflan...@hexagon.com<mailto:moritz.pflan...@hexagon.com><mailto:carolin.sieb...@hexagon.com>
> W: http://www.hexagongeosystems.com
> 
> 
> From: Jonathan Rajotte-Julien 
> Sent: 03 August 2020 17:31
> To: PFLANZER Moritz 
> Cc: lttng-dev@lists.lttng.org 
> Subject: Re: [lttng-dev] Help needed: No UST events recorded
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while 
> clicking links, opening attachments, or replying to this email.
> 
> 
> Hi Moritz
> 
> What is your version of lttng-tools?
> 
>   lttng --version
> 
> Please run the `hello` executable using the LTTNG_UST_DEBUG env variable, 
> while
> tracing, and provide the output.
> 
>   pkill lttng-sessiond
>   lttng-sessiond -b -vvv --verbose-consumer 2> /tmp/lttng-sessiond.log
>   lttng create
>   lttng enable-event -u -a
>   lttng start
>   LTTNG_UST_DEBUG=y ./hello
>   lttng stop
>   lttng destroy
>   pkill lttng-sessiond
> 
> Please also provide the /tmp/lttng-sessiond.log file via pastebin.
> 
> I suspect that if you cross-compiled lttng-ust from the master branch that
> lttng-tools is not using the same version, resulting in the application not
> being able to register to the lttng-sessiond.
> 
> Cheers
> 
> On Mon, Aug 03, 2020 at 09:35:25AM +, PFLANZER Moritz via lttng-dev wrote:
> > Hi all!
> >
> > I'm struggling to get userspace tracing working on an aarch64 platform 
> > (busybox on top of Linux 5.4.24 kernel). I followed the guidelines in the 
> > docs and am currently using this example program for testing: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flttng%2Flttng-ust%2Ftree%2Fmaster%2Fdoc%2Fexamples%2Fhello-static-libdata=02%7C01%7C%7Ce141a6eb68ea4d4c93c508d837c25b99%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637320655210160415sdata=lPbFWob0G4U22ncUmqfz12Ha42xOymctYWCOJC34oC8%3Dreserved=0
> > I cross-compiled lttng-ust and that example, but when I run the following 
> > commands on the platform no traces are recorded. If I use the same example 
> > on my x86 machine everything works as expected. (And kernelspace tracing is 
> > working on that aarch64 system.)
> >
> > Any hints where I could start investigating the issue are welcome.
> >
> > Regards,
> > Moritz
> >
> > ~ # pwd
> > /root
> > ~ # lttng create
> > Spawning a session daemon
> > Session auto-20200720-174509 created.
> > Traces will be written in /root/lttng-traces/auto-20200720-174509
> > ~ # lttng enable-event -au
> > All UST events are enabled in channel channel0
> > ~ # lttng start
> > Tracing started for session auto-20200720-174509
> > ~ # ./hello
> > Hello, World!
> > Tracing...  done.
> > ~ # lttng destroy
> > Session auto-20200720-174509 destroyed
> > ~ # ll
> > total 40
> > -rwxr-xr-x1 root root 39280 Jul 20 17:44 hello*
> >
> >
> >
> > Moritz Pflanzer
> > Software Development Engineer
> >
> > [cid:image001.png@01D3BF6E.185110B0]
&g

Re: [lttng-dev] Help needed: No UST events recorded

[Jonathan Rajotte-Julien via lttng-dev]

Hi Moritz

What is your version of lttng-tools?

  lttng --version

Please run the `hello` executable using the LTTNG_UST_DEBUG env variable, while
tracing, and provide the output.

  pkill lttng-sessiond
  lttng-sessiond -b -vvv --verbose-consumer 2> /tmp/lttng-sessiond.log
  lttng create
  lttng enable-event -u -a
  lttng start
  LTTNG_UST_DEBUG=y ./hello
  lttng stop
  lttng destroy
  pkill lttng-sessiond

Please also provide the /tmp/lttng-sessiond.log file via pastebin.

I suspect that if you cross-compiled lttng-ust from the master branch that
lttng-tools is not using the same version, resulting in the application not
being able to register to the lttng-sessiond.

Cheers

On Mon, Aug 03, 2020 at 09:35:25AM +, PFLANZER Moritz via lttng-dev wrote:
> Hi all!
> 
> I'm struggling to get userspace tracing working on an aarch64 platform 
> (busybox on top of Linux 5.4.24 kernel). I followed the guidelines in the 
> docs and am currently using this example program for testing: 
> https://github.com/lttng/lttng-ust/tree/master/doc/examples/hello-static-lib
> I cross-compiled lttng-ust and that example, but when I run the following 
> commands on the platform no traces are recorded. If I use the same example on 
> my x86 machine everything works as expected. (And kernelspace tracing is 
> working on that aarch64 system.)
> 
> Any hints where I could start investigating the issue are welcome.
> 
> Regards,
> Moritz
> 
> ~ # pwd
> /root
> ~ # lttng create
> Spawning a session daemon
> Session auto-20200720-174509 created.
> Traces will be written in /root/lttng-traces/auto-20200720-174509
> ~ # lttng enable-event -au
> All UST events are enabled in channel channel0
> ~ # lttng start
> Tracing started for session auto-20200720-174509
> ~ # ./hello
> Hello, World!
> Tracing...  done.
> ~ # lttng destroy
> Session auto-20200720-174509 destroyed
> ~ # ll
> total 40
> -rwxr-xr-x1 root root 39280 Jul 20 17:44 hello*
> 
> 
> 
> Moritz Pflanzer
> Software Development Engineer
> 
> [cid:image001.png@01D3BF6E.185110B0]
> 
> Räffelstrasse 28
> 
> 8045 Zürich
> E: 
> moritz.pflan...@hexagon.com<mailto:moritz.pflan...@hexagon.com><mailto:carolin.sieb...@hexagon.com>
> W: http://www.hexagongeosystems.com



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


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

Re: [lttng-dev] [EXTERNAL] Re: babeltrace cannot open the trace but Trace Compass can open

[Jonathan Rajotte-Julien via lttng-dev]

> When your account gets activated, could you copy this into the new
> issue's description?

I manually activated it. You should be good to go.

> 
> This way you can receive notifications when the issue gets updated.
> 
> Thank you,
> 
> Phil
> 
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] 回复：回复： 回复： some tracepoints not exist in metadata?

[Jonathan Rajotte-Julien via lttng-dev]

On Thu, Jul 02, 2020 at 08:38:57AM +0800, zhenyu.ren via lttng-dev wrote:
> Thanks a lot. I will try single quotes but it may take hours get the result.
> Yesterday, I enabled the verbose option ,and found the following message "UST
> app reply event failed. Application died (in add_event_ust_registry() at
> ust-app.c:5405)" and "UST app notify socket unregister 34 (in
> ust_app_notify_sock_unregister() at ust-app.c:5562)". In fact ,the socket that
> Lttng-sessiond send reply to my app return an error with EPIPE. It seems that
> the pipe breaked.So do you have any hint for that?

>From lttng master:
ret = ustctl_reply_register_event(sock, event_id, ret_code);
if (ret < 0) {
if (ret != -EPIPE && ret != -LTTNG_UST_ERR_EXITING) {
ERR("UST app reply event failed with ret %d", ret);
} else {
DBG3("UST app reply event failed. Application died");
}
/*
 * No need to wipe the create event since the application socket will
 * get close on error hence cleaning up everything by itself.
 */
goto error;
}

EPIPE ifor this socket is considered as an expected scenario.

This normally indicates a short-lived application or that your application
crashed while lttng-ust and lttng-tools were performing an event registration.
Considering that the path leading to the ustctl_reply_register_event call is
preceded by a call fetching information from the same socket
(ustctl_recv_register_event), I expect this to be a completely normal scenario
unless you provide evidence that this application under tracing was acting
normally and had a long lifetime.

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

Re: [lttng-dev] lttng_lib_ring_buffer: section 24 reloc 0 sym '': relocation 42 out of range

[Jonathan Rajotte-Julien via lttng-dev]

Hi Lukasz,

Is the problem reproducible on the qemu arm target (yocto) ?

On Thu, May 28, 2020 at 01:51:12PM +0200, Lukasz Domowy via lttng-dev wrote:
> Hello,
> 
> First - of all: thank you very much for efforts to develop and
> maintain LTTng. It's very useful tool!
> I used it so far on PowerPC targets and now I try to run it on ARM:
> Cyclone5 ARMv7 CPU.
> 
> When trying to run LTTng I get:
> 
> # lttng list --kernel
> [ 2012.822578] lttng_lib_ring_buffer: section 24 reloc 0 sym '':
> relocation 42 out of range (0x7f05827c -> 0xc0cd7358)
> Error: Unable to list kernel events: Kernel tracer not available
> Error: Command error
> 
> Do you have any hints how to fix it?
> 
> I found https://bugs.lttng.org/issues/1173 but enabling
> CONFIG_ARM_MODULE_PLTS did not help.
> 
> I use LTTng from Yocto 3.0.2 with custom kernel 4.14.134-rt63-rt:
> 
> # lttng -V
> lttng (LTTng Trace Control) 2.10.7 - KeKriek
> 
> All options recommended from documentation are enabled:
> root@cyclone5:~# zcat /proc/config.gz | grep -i modules
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_MODULES_USE_ELF_REL=y
> CONFIG_MODULES=y
> CONFIG_MODULES_TREE_LOOKUP=y
> # Xtables combined modules
> # User Modules And Translation Layers
> root@cyclone5:~# zcat /proc/config.gz | grep -i kallsyms
> CONFIG_KALLSYMS=y
> # CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
> CONFIG_KALLSYMS_BASE_RELATIVE=y
> root@cyclone5:~# zcat /proc/config.gz | grep -i high_res_timers
> CONFIG_HIGH_RES_TIMERS=y
> root@cyclone5:~# zcat /proc/config.gz | grep -i tracepoints
> CONFIG_TRACEPOINTS=y
> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> 
> Thank you in advance!
> 
> Best regards,
> Lukasz
> _______
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

Re: [lttng-dev] Need Help In trace generation for malloc(), free() calls etc

[Jonathan Rajotte-Julien via lttng-dev]

Hi Abhinav,

Please keep the mailing list in CC for all communication: 
lttng-dev@lists.lttng.org

If not, I am not interested in helping you further.

On Wed, May 13, 2020 at 09:26:52PM +0530, Abhinav Ranjan wrote:
> Hi! Jonathan thank you so much for your help and reply! Sure I'll not use
> snapshot from next time and follow your advice.
> In fact I figured out the issue, but Jonathan I have one specific doubt I
> wanted to trace malloc , free call from my app only  but after using lttng
> enable-event --userspace lttng_ust_libc:malloc I am seeing several malloc (
> in Trace Compass)   probably from different tracepoints from lttng_ust_libc.

You will see all malloc that the app does for its lifetime since you LD_PRELOAD
the wrapper including any allocation lttng-ust does. Keep in mind that lttng-ust
is not magic, lttng-ust spun threads and do some allocations to do its job.

What outcome do you expect? We might be able to at least get you on the right
path. In other word, what is your end goal?

Cheers

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

Re: [lttng-dev] Need Help In trace generation for malloc(), free() calls etc

[Jonathan Rajotte-Julien via lttng-dev]

Hi Abhinav,

Please refrain from using screenshots when pastebin could be used (code,
commands, etc).

On Wed, May 13, 2020 at 10:29:22AM +0530, Abhinav Ranjan via lttng-dev wrote:
>   Hello Sir,
> I am Abhinav from India.
> *Kindly Ignore the previous email.*
> Actually I am very new to the Embedded System Engineering profession. In
> fact I have been asked to do an independent project to instrumenting a c
> application using  LLTng concept to find/trace calls to malloc(), free()
> calls. In fact i tried capturing the same as below steps but didn't
> understand why after using LD_PRELOAD also malloc() and free() calls were
> not traced. I am not sure whether my app was correct!!
> 
>  I followed the steps provided to create executable using -lltng-ust -ldl
> 2.I executed it as: LD_PRELOAD=liblttng-ust-libc-wrapper.so ./executable
> (initially as ./exe arg))
> 3. Then I followed commands to create , capture the events. and destroyed
> it.

Based on the screenshot "creation_trace.PNG", it seems that you enable only the
event you defined (malloc_trace_investigation). Keep in mind that the libc
wrapper defines its own tracepoints and tracepoint providers.

It the case of the libc wrapper the tracepoint providers available are:
lttng_ust_libc and lttng_ust_pthread

Both have multiple tracepoints defined under them.

Hence what you want for you experiment is something like this:

lttng enable-event -u malloc_trace:investigation
lttng enable-event -u 'lttng_ust_libc:*'

Keep in mind that you can list the events available for a currently running app
using:

   lttng list -u


The app must be running for the listing work.

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

Re: [lttng-dev] Babeltrace 2.0.2 performance issue

[Jonathan Rajotte-Julien via lttng-dev]

Hi Aleksander,

On Thu, Apr 02, 2020 at 04:32:03PM +, Aleksander Aleksandrov via lttng-dev 
wrote:
> Hi Simon,
> 
> 
> Thank you for your message! Unfortunately, I missed your previous message, 
> sorry for this.
> 
> 
> I processed the CI's trace logs, I got the following performance: bt2 
> (140.51s) vs bt1 (122.00s). In my opinion, the values are quite similar 
> comparing with my other measurements.

Well, in that case we will augment the data gathered on our CI to better
understand what is happening here an why we have such discrepancy. I should be
able to allocate some time in the following weeks.

Feel free to contribute to the optimization effort on your end if you see any
big culprit. For now, the babeltrace team effort is primary on completing
documentation and internal cleanup.

On my laptop (Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz) with scaling enabled
(~3.2Ghz mean of freq used during the 5 run of each bt1 and bt2) I get extremely
similar result for both bt1 (~46s) and bt2(~45s).

On my desktop as Simon reported, (Ryzen 7 3700x , max freq 3.6Ghz), bt1 is ~33s 
and bt2 ~36s.

All of this using the dummy output for both bt1 and bt2.

Cheers

> 
> 
> Best regards,
> 
> Aleksandr
> 
> 
> On 2020-03-13 4:58 p.m., Simon Marchi wrote:
> > Hi Aleksander,
> >
> > I just noticed you did not send your original email to the lttng-dev 
> > mailing list,
> > please send such request on that mailing list, as it's of public interest:
> >
> >   https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >
> > See my previous response here:
> >
> >   https://pastebin.com/raw/3Q5PbYXn
> >
> > Simon
> >
> 
> Hi Aleksander,
> 
> Sorry, I forgot to follow up.  Did you get my last message?
> 
> This is the trace we use for benchmarking: 
> https://files.efficios.com/s/pog5raGkBkH63y9
> 
> Could you try to compare bt1 and bt2 using that trace?
> 
> On the CI benchmark system, we get some similar performance with both bt1 and 
> bt2.  Although
> a colleague tried on a recent AMD Ryzen 3700X CPU, and he says bt2 is slower 
> than bt1 for
> him (36s vs 33s).  I'd be curious to know what kind of numbers you get.
> 
> Simon

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


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

Re: [lttng-dev] Large number of stream files in CTF trace -- too many file handles

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

> If this is not the right approach, how should I proceed?  E.g., should the
> source-ctf-fs manage a limited pool of file handles?  I would think this
> would be pretty inefficient as you would need to constantly open/close
> files--expensive.

I would probably start looking at the soft and hardlimit for the babeltrace2
process in terms of open file:

On my machine:

joraj@~[]$ ulimit -Sn
1024

joraj@~[]$ ulimit -Hn
1048576

That is a lot of headspace.

I might have a setting somewhere increasing the base hardlimit but
in any case you will see how much room you have.

Based on the number of streams you have, I would say that you will
need more than 2000 as a base soft limit for this trace.

We do have a FD pooling system in place in another project we maintain
(lttng-tools[1] GPL-2.0) that might be pertinent for babeltrace2 at some point
in time. As for the overhead that would occur in a scenario with not enough FD
available, I think it is a good compromise between either reading a trace or
not reading it at all. A warning informing the user that we reached
the limit of the pool might be a good start in such case.

[1] https://github.com/lttng/lttng-tools/tree/master/src/common/fd-tracker

Cheers

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

Re: [lttng-dev] bt2 Python quick start/examples?

[Jonathan Rajotte-Julien via lttng-dev]

Hi,

On Wed, Mar 11, 2020 at 10:56:24PM -0400, Rocky Dunlap via lttng-dev wrote:
> I see that the bt2 Python documentation is not yet ready:
> https://babeltrace.org/docs/v2.0/python/bt2/

Slowly getting there.

> 
> In lieu of that, where is the best place to find at least a few examples of
> using the bt2 Python API for basic trace processing tasks?

Simon Marchi have some examples [1] that have been used in his talk [2][3].

Hope this helps a bit.


[1] https://github.com/simark/babeltrace-fun-plugins
[2] https://www.youtube.com/watch?v=P3cPISvW444=youtu.be
[3] 
https://tracingsummit.org/ts/2019/files/Tracingsummit2019-babeltrace2-marchi.pdf


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

Re: [lttng-dev] Measure loop rate

[Jonathan Rajotte-Julien]

Hi,

On Wed, Jan 22, 2020 at 06:28:14PM +0100, bhanu kiran chaluvadi wrote:
> Hi ,
> 
> I am trying to observer loop rate of a while loop.  Ideally it should take
> maximum of 2 ms to finish the cycle (500 Hz at least). And i would like to
> trace the loop rate using LTTng user space. whats the better way of doing
> it ..Just place one trace point at the start and one at the end ? or is
> there any library that i can take advantage of?

I'm not completely sure what you mean by "loop rate" but if you are looking for
the duration of a single iteration of your while loop then yes, one at the start
and one at the end. Keep in mind that tracing is *not* free and that you will
need to account for the tracing overhead here. I would suggest having no payload
at all if you can.

There is other ways of deducing the time taken by one iteration (time_for_n/n)
to reduce impact of tracing if you can have an upper bound (or know the number
of iterations that took place) for the number of iterations but it will only
give you the mean time for the loop execution. In that case, the tracepoints
would be outside the while loop.

You could also hit an event only each X loop iterations and deduce the
rate from there. Keep in mind that this will require accounting and
will add to the workload etc.

It all depends on the granularity you are looking for.

Cheers
-- 
Jonathan Rajotte-Julien
EfficiOS
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Regarding LTTNG support for Containers

[Jonathan Rajotte-Julien]

Hi,

On Mon, Dec 16, 2019 at 12:39:33PM +0530, Yogesh Chandolia via lttng-dev wrote:
> Hi Team,
> 
> 
> 
> We are planning to use LTTng2.11 for tracing the application in user-space
> using the LTTng-UST library only. Our application will run in the
> container.

Where do you plan on running the session daemon and consumer daemon?

> 
> We have query regarding the support of LTTng-UST for the containerize
> environment.
> 
> Please let us know whether LTTng support the tracing for containerize
> application. If yes, please share the documentation of LTTng-UST support
> for container environment.
> 
> 
> Thanks & Regards,
> 
> Yogesh
> 
> Mobile: +91 9910094311
> 
> Email: yogesh.chando...@globallogic.com
> 
> Skype ID: yogesh.chando...@globalogicindia.onmicrosoft.com

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


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

[lttng-dev] [PATCH lttng-tools v2] Fix: update apps on untrack only when session is active

[Jonathan Rajotte]

This mimics what is done on the track side.

Fixes #1210

Signed-off-by: Jonathan Rajotte 
---

Used wrong issue number.

---
 src/bin/lttng-sessiond/trace-ust.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/bin/lttng-sessiond/trace-ust.c 
b/src/bin/lttng-sessiond/trace-ust.c
index 486b53d30..a6c0c04ad 100644
--- a/src/bin/lttng-sessiond/trace-ust.c
+++ b/src/bin/lttng-sessiond/trace-ust.c
@@ -922,6 +922,7 @@ end:
 int trace_ust_untrack_pid(struct ltt_ust_session *session, int pid)
 {
int retval = LTTNG_OK;
+   bool should_update_apps = false;
 
if (pid == -1) {
/* Create empty tracker, replace old tracker. */
@@ -938,7 +939,7 @@ int trace_ust_untrack_pid(struct ltt_ust_session *session, 
int pid)
fini_pid_tracker(_tracker);
 
/* Remove session from all applications */
-   ust_app_global_update_all(session);
+   should_update_apps = true;
} else {
int ret;
struct ust_app *app;
@@ -957,9 +958,12 @@ int trace_ust_untrack_pid(struct ltt_ust_session *session, 
int pid)
/* Remove session from application. */
app = ust_app_find_by_pid(pid);
if (app) {
-   ust_app_global_update(session, app);
+   should_update_apps = true;
}
}
+   if (should_update_apps && session->active) {
+   ust_app_global_update_all(session);
+   }
 end:
return retval;
 }
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools] Fix: update apps on untrack only when session is active

[Jonathan Rajotte]

This mimics what is done on the track side.

Fixes #1209

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/trace-ust.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/bin/lttng-sessiond/trace-ust.c 
b/src/bin/lttng-sessiond/trace-ust.c
index 486b53d30..a6c0c04ad 100644
--- a/src/bin/lttng-sessiond/trace-ust.c
+++ b/src/bin/lttng-sessiond/trace-ust.c
@@ -922,6 +922,7 @@ end:
 int trace_ust_untrack_pid(struct ltt_ust_session *session, int pid)
 {
int retval = LTTNG_OK;
+   bool should_update_apps = false;
 
if (pid == -1) {
/* Create empty tracker, replace old tracker. */
@@ -938,7 +939,7 @@ int trace_ust_untrack_pid(struct ltt_ust_session *session, 
int pid)
fini_pid_tracker(_tracker);
 
/* Remove session from all applications */
-   ust_app_global_update_all(session);
+   should_update_apps = true;
} else {
int ret;
struct ust_app *app;
@@ -957,9 +958,12 @@ int trace_ust_untrack_pid(struct ltt_ust_session *session, 
int pid)
/* Remove session from application. */
app = ust_app_find_by_pid(pid);
if (app) {
-   ust_app_global_update(session, app);
+   should_update_apps = true;
}
}
+   if (should_update_apps && session->active) {
+   ust_app_global_update_all(session);
+   }
 end:
return retval;
 }
-- 
2.17.1

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

Re: [lttng-dev] 回复:Re: 回复:Re: 回复:Re: Pros and Cons of LTTng

[Jonathan Rajotte-Julien]

Hi,

On Wed, Nov 06, 2019 at 11:59:41AM +0800, 杨海 wrote:
> Thanks Jonathan. Regarding to the CI MTTR/MTTF test results, it varies from 
> time to time, and on master/stable branches.
> 1. it monitors new Linux kernels, so the CI job may use newer kernel version 
> than months ago?

Not sure of the question here but here more information on how to jobs works.

The job monitor all kernel tags that we deems pertinent for example for the
vanilla kernel (linux-stable) with the lttng-modules master branch [1]:

  09:13:52 Building the following kernel versions:
  09:13:52 v3.0.101
  09:13:52 v3.1.10
  09:13:52 v3.2.102
  09:13:52 v3.3.8
  09:13:52 v3.4.113
  09:13:52 v3.5.7
  09:13:52 v3.6.11
  09:13:52 v3.7.10
  09:13:52 v3.8.13
  09:13:52 v3.9.11
  09:13:52 v3.10.108
  09:13:52 v3.11.10
  09:13:52 v3.12.74
  09:13:52 v3.13.11
  09:13:52 v3.14.79
  09:13:52 v3.15.10
  09:13:52 v3.16.76
  09:13:52 v3.17.8
  09:13:52 v3.18.140
  09:13:52 v3.19.8
  09:13:52 v4.0.9
  09:13:52 v4.1.52
  09:13:52 v4.2.8
  09:13:52 v4.3.6
  09:13:52 v4.4.199
  09:13:52 v4.5.7
  09:13:52 v4.6.7
  09:13:52 v4.7.10
  09:13:52 v4.8.17
  09:13:52 v4.9.199
  09:13:52 v4.10.17
  09:13:52 v4.11.12
  09:13:52 v4.12.14
  09:13:52 v4.13.16
  09:13:52 v4.14.152
  09:13:52 v4.15.18
  09:13:52 v4.16.18
  09:13:52 v4.17.19
  09:13:52 v4.18.20
  09:13:52 v4.19.82
  09:13:52 v4.20.17
  09:13:52 v5.0.21
  09:13:52 v5.1.21
  09:13:52 v5.2.21
  09:13:52 v5.3.9
  09:13:52 v5.4-rc6

We always track the latest tag of each branch. This does not mean that we do not
support smaller tag of a branch, only that support is a best effort based on
user feedback. Tracking all tags would represent a monumental effort and would
require way more resource overall. Not something we are against, simply that we
do not have the resource for it.

[1] 
https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/

Note the last rc kernel tag.

Note that we also perform this for some distros and their kernels:

https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_crossbuild-xenial/
https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_crossbuild-bionic/

I guess that it is true that we do not test against past kernel tag for each
branch. Given our history and process, most time that lttng-modules is broken is
that distro are taking liberty on patch backporting. These get fixed asap and
backported to all supported lttng-modules stable branches. 
> 2. What would be the criteria of MTBF here?

Note that these statistics have little to no value here due to the presence of 
the
testing against RC tags. These tags will breaks lttng-modules one way or another
and it is a good thing. This allows us to keep up to date with upstream.
The only pertinent value is the MTTR here. It shows our responsiveness to
external change.

A better representation of our MTTR would be the jobs following distros:

https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-xenial/

MTTRLast 7 Days0 ms
Last 30 Days   0 ms
All Time   15 hr
MTTFLast 7 Days0 ms
Last 30 Days   0 ms
All Time   4 mo 5 days

Here our MTTR is 15h. Which is quite quick considering the context of tracking
kernel outside of our control.

MTTR is from the moment the CI detect a problem and that we provide a fix for
it.

MTTF is not something we can have control over since the source is completely
external. Except for the rare event that the infrastructure is deficient.

TBH these statistic have little to no meaning in this context.

Cheers

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

Re: [lttng-dev] 回复:Re: 回复:Re: 回复:Re: Pros and Cons of LTTng

[Jonathan Rajotte-Julien]

Hi,

On Mon, Nov 04, 2019 at 11:47:58AM +0800, 杨海 wrote:
> Hi
> 
> 
> As you previously commented, “The current LTTng kernel tracer (lttng-modules) 
> supports Linux 3.0+ only.” and we can find the support package list on 
> http://packages.efficios.com/.;
> Does LTTng have roadmap for upcoming new kernel versions?

I presume you are explicitly asking for RHEL & SUSE kernels. The current
packages for these distro are maintained on a best effort and commercial
incentive of EfficiOS. If you are interested in supporting this effort please
contact sa...@efficios.com.

As for the actual upstream kernel, we are monitoring [1] all new kernels and
stable branches.


[1] https://ci.lttng.org/view/LTTng-modules/

https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_stable-2.9_build-vanilla/

https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_stable-2.10_build-vanilla/

https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_stable-2.11_build-vanilla/

https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/

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

[lttng-dev] [PATCH lttng-tools 5/5] Tests: fix shellcheck warning

[Jonathan Rajotte]

No need to use random string for session name here, use the test name.

Signed-off-by: Jonathan Rajotte 
---
 tests/regression/tools/base-path/test_ust | 36 ++-
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/tests/regression/tools/base-path/test_ust 
b/tests/regression/tools/base-path/test_ust
index d60a2302a..84d434551 100755
--- a/tests/regression/tools/base-path/test_ust
+++ b/tests/regression/tools/base-path/test_ust
@@ -16,10 +16,8 @@
 # 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301 USA
 TEST_DESC="Streaming Base Path Override - User space tracing"
 
-CURDIR=$(dirname $0)/
+CURDIR=$(dirname "$0")/
 TESTDIR=$CURDIR/../../..
-NR_ITER=5
-NR_USEC_WAIT=0
 TESTAPP_PATH="$TESTDIR/utils/testapp"
 TESTAPP_NAME="gen-ust-events"
 TESTAPP_BIN="$TESTAPP_PATH/$TESTAPP_NAME/$TESTAPP_NAME"
@@ -29,7 +27,7 @@ TRACE_PATH=$(mktemp -d)
 
 NUM_TESTS=37
 
-source $TESTDIR/utils/utils.sh
+source "$TESTDIR/utils/utils.sh"
 
 if [ ! -x "$TESTAPP_BIN" ]; then
BAIL_OUT "No UST events binary detected."
@@ -37,7 +35,7 @@ fi
 
 function ust_app_stream_base_path ()
 {
-   local session_name=$(randstring 16 0)
+   local session_name="ust_app_stream_base_path"
local base_path="my/custom/path1"
 
diag "Test base path override for trace streaming"
@@ -52,16 +50,15 @@ function ust_app_stream_base_path ()
destroy_lttng_session_ok $session_name
 
# validate test
-   validate_trace $EVENT_NAME $TRACE_PATH/$HOSTNAME/$base_path
-   if [ $? -eq 0 ]; then
+   if validate_trace $EVENT_NAME "$TRACE_PATH/$HOSTNAME/$base_path"; then
# only delete if successful
-   rm -rf $TRACE_PATH
+   rm -rf "$TRACE_PATH"
fi
 }
 
 function ust_app_snapshot_create_base_path ()
 {
-   local session_name=$(randstring 16 0)
+   local session_name="ust_app_snapshot_create_base_path"
local base_path="my/custom/path2"
 
diag "Test base path override for remote trace snapshot (URI on create)"
@@ -80,16 +77,15 @@ function ust_app_snapshot_create_base_path ()
destroy_lttng_session_ok $session_name
 
# validate test
-   validate_trace $EVENT_NAME $TRACE_PATH/$HOSTNAME/$base_path
-   if [ $? -eq 0 ]; then
+   if validate_trace $EVENT_NAME "$TRACE_PATH/$HOSTNAME/$base_path"; then
# only delete if successful
-   rm -rf $TRACE_PATH
+   rm -rf "$TRACE_PATH"
fi
 }
 
 function ust_app_snapshot_base_path ()
 {
-   local session_name=$(randstring 16 0)
+   local session_name="ust_app_snapshot_base_path"
local base_path="my/custom/path3"
 
diag "Test base path override for remote trace snapshot (URI on 
snapshot)"
@@ -107,16 +103,15 @@ function ust_app_snapshot_base_path ()
destroy_lttng_session_ok $session_name
 
# validate test
-   validate_trace $EVENT_NAME $TRACE_PATH/$HOSTNAME/$base_path
-   if [ $? -eq 0 ]; then
+   if validate_trace $EVENT_NAME "$TRACE_PATH/$HOSTNAME/$base_path"; then
# only delete if successful
-   rm -rf $TRACE_PATH
+   rm -rf "$TRACE_PATH"
fi
 }
 
 function ust_app_snapshot_add_output_base_path ()
 {
-   local session_name=$(randstring 16 0)
+   local session_name="ust_app_snapshot_add_output_base_path"
local base_path="my/custom/path4"
 
diag "Test base path override for remote trace snapshot (URI on 
add-output)"
@@ -135,10 +130,9 @@ function ust_app_snapshot_add_output_base_path ()
destroy_lttng_session_ok $session_name
 
# validate test
-   validate_trace $EVENT_NAME $TRACE_PATH/$HOSTNAME/$base_path
-   if [ $? -eq 0 ]; then
+   if validate_trace $EVENT_NAME "$TRACE_PATH/$HOSTNAME/$base_path"; then
# only delete if successful
-   rm -rf $TRACE_PATH
+   rm -rf "$TRACE_PATH"
fi
 }
 
@@ -176,7 +170,7 @@ tests=( ust_app_stream_base_path
ust_app_snapshot_add_output_base_path
ust_app_stream_base_path_via_load
 )
-for fct_test in ${tests[@]};
+for fct_test in "${tests[@]}";
 do
${fct_test}
 done
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools 3/5] Cleanup: remove unused internal lttng_session_descriptor_get_base_path

[Jonathan Rajotte]

Signed-off-by: Jonathan Rajotte 
---

Feel free to squash this into the previous commits.

---
 include/lttng/session-descriptor-internal.h |  4 
 src/common/session-descriptor.c | 23 -
 2 files changed, 27 deletions(-)

diff --git a/include/lttng/session-descriptor-internal.h 
b/include/lttng/session-descriptor-internal.h
index 18a70bad4..09d493393 100644
--- a/include/lttng/session-descriptor-internal.h
+++ b/include/lttng/session-descriptor-internal.h
@@ -109,8 +109,4 @@ int lttng_session_descriptor_assign(
struct lttng_session_descriptor *dst_descriptor,
const struct lttng_session_descriptor *src_descriptor);
 
-LTTNG_HIDDEN
-int lttng_session_descriptor_get_base_path(struct lttng_session_descriptor 
*dst,
-   const char **base_path);
-
 #endif /* LTTNG_SESSION_DESCRIPTOR_INTERNAL_H */
diff --git a/src/common/session-descriptor.c b/src/common/session-descriptor.c
index 6dea5ee7c..224138dd2 100644
--- a/src/common/session-descriptor.c
+++ b/src/common/session-descriptor.c
@@ -1176,26 +1176,3 @@ int lttng_session_descriptor_assign(
 end:
return ret;
 }
-
-LTTNG_HIDDEN
-int lttng_session_descriptor_get_base_path(struct lttng_session_descriptor 
*dst,
-   const char **_base_path)
-{
-   switch (dst->output_type) {
-   case LTTNG_SESSION_DESCRIPTOR_OUTPUT_TYPE_NETWORK:
-   {
-   if (dst->output.network.control &&
-   dst->output.network.control->subdir[0]) {
-   *_base_path = dst->output.network.control->subdir;
-   } else {
-   *_base_path = NULL;
-   }
-   break;
-   }
-   case LTTNG_SESSION_DESCRIPTOR_OUTPUT_TYPE_LOCAL:
-   case LTTNG_SESSION_DESCRIPTOR_OUTPUT_TYPE_NONE:
-   *_base_path = NULL;
-   break;
-   }
-   return 0;
-}
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools 2/5] Refactor: Move set session path to own function

[Jonathan Rajotte]

Signed-off-by: Jonathan Rajotte 
---

Feel free to squash this into the previous commit.

---
 src/bin/lttng-sessiond/cmd.c | 64 +---
 1 file changed, 44 insertions(+), 20 deletions(-)

diff --git a/src/bin/lttng-sessiond/cmd.c b/src/bin/lttng-sessiond/cmd.c
index 1dec61ea1..3ee390698 100644
--- a/src/bin/lttng-sessiond/cmd.c
+++ b/src/bin/lttng-sessiond/cmd.c
@@ -2739,6 +2739,42 @@ error:
return ret;
 }
 
+/*
+ * Set the base_path of the session only if subdir of a control uris is set.
+ * Return LTTNG_OK on success, otherwise LTTNG_ERR_*.
+ */
+static int set_session_base_path_from_uris(struct ltt_session *session,
+   size_t nb_uri,
+   struct lttng_uri *uris)
+{
+   int ret;
+   for (int i = 0; i < nb_uri; i++) {
+   if (uris[i].stype != LTTNG_STREAM_CONTROL ||
+   uris[i].subdir[0] == '\0') {
+   /* Not interested in these URIs */
+   continue;
+   }
+
+   if (session->base_path != NULL) {
+   free(session->base_path);
+   session->base_path = NULL;
+   }
+
+   /* Set session base_path */
+   session->base_path = strdup(uris[i].subdir);
+   if (!session->base_path) {
+   PERROR("Copying base path: %s", uris[i].subdir);
+   ret = LTTNG_ERR_NOMEM;
+   goto error;
+   }
+   DBG2("Setting base path for session %" PRIu64 ": %s",
+   session->id, session->base_path);
+   }
+   ret = LTTNG_OK;
+error:
+   return ret;
+}
+
 /*
  * Command LTTNG_SET_CONSUMER_URI processed by the client thread.
  */
@@ -2759,26 +2795,14 @@ int cmd_set_consumer_uri(struct ltt_session *session, 
size_t nb_uri,
goto error;
}
 
-   for (i = 0; i < nb_uri; i++) {
-   if (uris[i].stype != LTTNG_STREAM_CONTROL ||
-   uris[i].subdir[0] == '\0') {
-   /* Not interested in these URIs */
-   continue;
-   }
-
-   if (session->base_path != NULL) {
-   free(session->base_path);
-   session->base_path = NULL;
-   }
-
-   /* Set session base_path */
-   session->base_path = strdup(uris[i].subdir);
-   if (!session->base_path) {
-   PERROR("Copying base path: %s", uris[i].subdir);
-   goto error;
-   }
-   DBG2("Setting base path for session %" PRIu64 ": %s",
-   session->id, session->base_path);
+   /*
+* Set the session base path if any. This is done inside
+* cmd_set_consumer_uri to preserve backward compatibility of the
+* previous session creation api vs the session descriptor api.
+*/
+   ret = set_session_base_path_from_uris(session, nb_uri, uris);
+   if (ret != LTTNG_OK) {
+   goto error;
}
 
/* Set the "global" consumer URIs */
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools 4/5] Tests: base path: lttng load for session configuration

[Jonathan Rajotte]

Signed-off-by: Jonathan Rajotte 
---
 .../base-path/load-stream-extra-path.lttng| 66 +++
 tests/regression/tools/base-path/test_ust | 29 +++-
 2 files changed, 92 insertions(+), 3 deletions(-)
 create mode 100644 
tests/regression/tools/base-path/load-stream-extra-path.lttng

diff --git a/tests/regression/tools/base-path/load-stream-extra-path.lttng 
b/tests/regression/tools/base-path/load-stream-extra-path.lttng
new file mode 100644
index 0..973d67a6d
--- /dev/null
+++ b/tests/regression/tools/base-path/load-stream-extra-path.lttng
@@ -0,0 +1,66 @@
+
+
+   
+   load-stream-extra-path
+   
+   
+   UST
+   PER_UID
+   
+   
+   channel0
+   true
+   
DISCARD
+   
524288
+   
4
+   
0
+   
0
+   MMAP
+   
0
+   
100
+   
0
+   
0
+   
0
+   
+   
+   
tp:tptest
+   
true
+   
TRACEPOINT
+   
ALL
+   
+   
+   
+   
+   
+   
+   
+   
+   JUL
+   PER_UID
+   
+   
+   
+   LOG4J
+   PER_UID
+   
+   
+   
+   PYTHON
+   PER_UID
+   
+   
+   
+   false
+   
+   
+   true
+   
+   
+   
tcp4://127.0.0.1:5342/my/custom/path5
+   
tcp4://127.0.0.1:5343/
+   
+   
+   
+   
+   
+
diff --git a/tests/regression/tools/base-path/test_ust 
b/tests/regression/tools/base-path/test_ust
index d7e324e7b..d60a2302a 100755
--- a/tests/regression/tools/base-path/test_ust
+++ b/tests/regression/tools/base-path/test_ust
@@ -27,7 +27,7 @@ EVENT_NAME="tp:tptest"
 
 TRACE_PATH=$(mktemp -d)
 
-NUM_TESTS=32
+NUM_TESTS=37
 
 source $TESTDIR/utils/utils.sh
 
@@ -117,7 +117,7 @@ function ust_app_snapshot_base_path ()
 function ust_app_snapshot_add_output_base_path ()
 {
local session_name=$(randstring 16 0)
-   local base_path="my/custom/path3"
+   local base_path="my/custom/path4"
 
diag "Test base path override for remote trace snapshot (URI on 
add-output)"
create_lttng_session_no_output $session_name --snapshot
@@ -142,6 +142,27 @@ function ust_app_snapshot_add_output_base_path ()
fi
 }
 
+function ust_app_stream_base_path_via_load ()
+{
+   local session_name="load-stream-extra-path"
+   local base_path="my/custom/path5"
+
+   diag "Test base path override for trace streaming using lttng load"
+   lttng_load_ok "-i $CURDIR/$session_name.lttng"
+   start_lttng_tracing_ok $session_name
+
+   $TESTAPP_BIN > /dev/null 2>&1
+
+   stop_lttng_tracing_ok $session_name
+   destroy_lttng_session_ok $session_name
+
+   # validate test
+   if validate_trace $EVENT_NAME "$TRACE_PATH/$HOSTNAME/$base_path"; then
+   # only delete if successful
+   rm -rf "$TRACE_PATH"
+   fi
+}
+
 plan_tests $NUM_TESTS
 
 print_test_banner "$TEST_DESC"
@@ -152,7 +173,9 @@ start_lttng_sessiond
 tests=( ust_app_stream_base_path
ust_app_snapshot_create_base_path

[lttng-dev] [PATCH lttng-tools 1/5] Fix: move set base_path of session to URI configuration

[Jonathan Rajotte]

The load code still use the "old" API to create and configure network
session output (lttng_create_session followed by
lttng_set_consumer_url). The session base_path is only set in the
cmd_create_session_from_descriptor function. This results in invalid
network output path when using a loaded session configuration (xml).

While we might want to move the load code to the new API, there is a case
to be made in not breaking the previous API behaviour.

To restore the expected behaviour of lttng_set_consumer_url, move the
assignation of the session base_path to the cmd_set_consumer_uri function
(LTTNG_SET_CONSUMER_URI).

Both the previous and session descriptor based creation API uses this code
path when needed (network output).

Signed-off-by: Jonathan Rajotte 
---

Note that this is the "base fix". The next 2 commits extracts the added for
loops into its own function and also remove
lttng_session_descriptor_get_base_path from the code base. Feel free to "squash"
them. I was not sure what you would prefer.

---
 src/bin/lttng-sessiond/cmd.c | 36 +++-
 src/bin/lttng-sessiond/session.c | 12 +--
 src/bin/lttng-sessiond/session.h |  2 +-
 tests/unit/test_session.c|  4 ++--
 4 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/src/bin/lttng-sessiond/cmd.c b/src/bin/lttng-sessiond/cmd.c
index a164cffc0..1dec61ea1 100644
--- a/src/bin/lttng-sessiond/cmd.c
+++ b/src/bin/lttng-sessiond/cmd.c
@@ -2759,11 +2759,32 @@ int cmd_set_consumer_uri(struct ltt_session *session, 
size_t nb_uri,
goto error;
}
 
+   for (i = 0; i < nb_uri; i++) {
+   if (uris[i].stype != LTTNG_STREAM_CONTROL ||
+   uris[i].subdir[0] == '\0') {
+   /* Not interested in these URIs */
+   continue;
+   }
+
+   if (session->base_path != NULL) {
+   free(session->base_path);
+   session->base_path = NULL;
+   }
+
+   /* Set session base_path */
+   session->base_path = strdup(uris[i].subdir);
+   if (!session->base_path) {
+   PERROR("Copying base path: %s", uris[i].subdir);
+   goto error;
+   }
+   DBG2("Setting base path for session %" PRIu64 ": %s",
+   session->id, session->base_path);
+   }
+
/* Set the "global" consumer URIs */
for (i = 0; i < nb_uri; i++) {
-   ret = add_uri_to_consumer(session,
-   session->consumer,
-   [i], LTTNG_DOMAIN_NONE);
+   ret = add_uri_to_consumer(session, session->consumer, [i],
+   LTTNG_DOMAIN_NONE);
if (ret != LTTNG_OK) {
goto error;
}
@@ -2894,7 +2915,6 @@ enum lttng_error_code cmd_create_session_from_descriptor(
const char *session_name;
struct ltt_session *new_session = NULL;
enum lttng_session_descriptor_status descriptor_status;
-   const char *base_path;
 
session_lock_list();
if (home_path) {
@@ -2917,13 +2937,9 @@ enum lttng_error_code cmd_create_session_from_descriptor(
ret_code = LTTNG_ERR_INVALID;
goto end;
}
-   ret = lttng_session_descriptor_get_base_path(descriptor, _path);
-   if (ret) {
-   ret_code = LTTNG_ERR_INVALID;
-   goto end;
-   }
+
ret_code = session_create(session_name, creds->uid, creds->gid,
-   base_path, _session);
+   _session);
if (ret_code != LTTNG_OK) {
goto end;
}
diff --git a/src/bin/lttng-sessiond/session.c b/src/bin/lttng-sessiond/session.c
index 383c6fde7..ed68d153f 100644
--- a/src/bin/lttng-sessiond/session.c
+++ b/src/bin/lttng-sessiond/session.c
@@ -962,7 +962,7 @@ end:
  * Session list lock must be held by the caller.
  */
 enum lttng_error_code session_create(const char *name, uid_t uid, gid_t gid,
-   const char *base_path, struct ltt_session **out_session)
+   struct ltt_session **out_session)
 {
int ret;
enum lttng_error_code ret_code;
@@ -1086,16 +1086,6 @@ enum lttng_error_code session_create(const char *name, 
uid_t uid, gid_t gid,
}
}
 
-   if (base_path) {
-   new_session->base_path = strdup(base_path);
-   if (!new_session->base_path) {
-   ERR("Failed to allocate base path of session \"%s\"",
-   name);
-   ret_code = LTTNG_ERR_SESSION_FAIL;
-   goto error;
-   }
-   }
-
new

[lttng-dev] [PATCH lttng-tools] Fix: initialize sessions pointer to NULL

[Jonathan Rajotte]

lttng_list_sessions does not set the passed pointer to NULL on empty
return. This lead to deallocation of non-allocated memory (segfault).

For returns of size 0, the value of the passed argument should be
considered "undefined".

Refactor error handling a bit by removing the "error" jump. Always call
free on the sessions object.

Fixes #1205

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng/commands/list.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/bin/lttng/commands/list.c b/src/bin/lttng/commands/list.c
index 28166c8be..65d8ea6f5 100644
--- a/src/bin/lttng/commands/list.c
+++ b/src/bin/lttng/commands/list.c
@@ -1825,7 +1825,7 @@ static int list_sessions(const char *session_name)
int ret = CMD_SUCCESS;
int count, i;
unsigned int session_found = 0;
-   struct lttng_session *sessions;
+   struct lttng_session *sessions = NULL;
 
count = lttng_list_sessions();
DBG("Session count %d", count);
@@ -1838,7 +1838,7 @@ static int list_sessions(const char *session_name)
if (lttng_opt_mi) {
/* Mi */
if (session_name == NULL) {
-   /* List all session */
+   /* List all sessions */
ret = mi_list_sessions(sessions, count);
} else {
/* Note : this return an open session element */
@@ -1846,7 +1846,7 @@ static int list_sessions(const char *session_name)
}
if (ret) {
ret = CMD_ERROR;
-   goto error;
+   goto end;
}
} else {
/* Pretty print */
@@ -1893,7 +1893,7 @@ static int list_sessions(const char *session_name)
if (!session_found && session_name != NULL) {
ERR("Session '%s' not found", session_name);
ret = CMD_ERROR;
-   goto error;
+   goto end;
}
 
if (session_name == NULL) {
@@ -1901,9 +1901,8 @@ static int list_sessions(const char *session_name)
}
}
 
-error:
-   free(sessions);
 end:
+   free(sessions);
return ret;
 }
 
-- 
2.17.1

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

Re: [lttng-dev] Trace Compass "Add contexts..." option displays XML file

[Jonathan Rajotte-Julien]

Hi,

On Wed, Oct 23, 2019 at 12:33:59PM +, Kramer, Zach wrote:
> Hi,
> 
> With 2.11.0, adding contexts no longer works for me in Trace Compass (5.1.0). 
> This worked before in lttng-tools 2.9.11.
> 
> When I try to add contexts to my channel I get the following options:
> 
>   *   All Contexts
>  *   
>  * // Entire XML file

Actually the mi support for listing context was added in 2.11 [1]. This seems 
to be
tracecompass expecting regular text output despite it is passing the "--mi xml"
options. Please repost this on the tracecompass mailing list [2].

[1] 
https://github.com/lttng/lttng-tools/commit/59deec0c09b544d548711deaa6d8206efe99ea0d
[2] https://accounts.eclipse.org/mailing-list/tracecompass-dev

Cheers

> 
> Does anyone else experience this? Did the XML schema change in a way that 
> requires Trace Compass to update its parsing?
> 
> lttng add-context –list works as expected.
> 
> Best,
> Zach
> 

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


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

Re: [lttng-dev] [2.11.0] Saving then loading network session loses absolute path

[Jonathan Rajotte-Julien]

Hi,

Indeed this is not expected. I was able to reproduce.

I am looking into it.

Thanks for reporting.

Cheers

On Mon, Oct 21, 2019 at 03:27:50PM +, Kramer, Zach wrote:
> Hi,
> 
> With all LTTng versions being 2.11.0 I have the following problem:
> 
> lttng-sessiond -d
> lttng-relayd -d
> 
> lttng create example –set-url=net://localhost/test
> OR
> lttng create example --live –set-url=net://localhost/test
> NOT
> lttng create example –set-url=file:///home//lttng-traces/test
> 
> lttng enable-channel -u ch
> lttng enable-event -u -a -c ch -s example
> lttng start example
> 
> (traces are written to ~/lttng-traces//test)
> 
> lttng stop example
> lttng save example
> lttng destroy example
> (remove lttng-traces/ for testing purposes)
> 
> lttng load example
> lttng start example
> 
> (traces now exist in ~/lttng-traces//example-)
> 
> This is, for me, reproducible 100% of the time. I can reproduce the steps 
> using the Trace Compass control view as well. If I override the session name 
> and url, the problem persists.
> 
> The .lttng file seems valid (attached). This issue exists whether I use an 
> existing .lttng file from 2.9 (which never showed this problem), or whether I 
> create a new one like above.
> 
> Is this intended behavior? If not, any idea what could be happening here? Is 
> this reproducible by others?
> 
> Best,
> Zach
> 


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


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

[lttng-dev] LTTng 2.11 new features blog posts

[Jonathan Rajotte-Julien]

Hello everyone!

We recently published two blog posts [1][2] concerning upcoming features of
LTTng 2.11.

[1] introduces the new session rotation feature allowing users to create
self-contained trace archives on-demand that can be analyzed while tracing
continues in the background.

[2] demonstrates how to leverage the new dynamic userspace probe support. It
allows you to add tracepoints in running apps without needing to recompile or
even restart them. It supports instrumentation on ELF function symbol and
Systemtap’s SDT probe points.

Cheers

[1] https://lttng.org/blog/2019/10/15/lttng-session-rotation/
[2] https://lttng.org/blog/2019/10/15/new-dynamic-user-space-tracing-in-lttng/

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

Re: [lttng-dev] Difficulty extending existing tracepoint's reporting

[Jonathan Rajotte-Julien]

Hi David,

Did you add the lttng tracepoint definition in 
instrumentation/events/lttng-module/block.h
as it is done with block_rq_complete? (in lttng-modules source tree)

Cheers

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

Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID

[Jonathan Rajotte-Julien]

On Tue, Sep 24, 2019 at 04:13:13PM +, Kramer, Zach wrote:
> Hi Jonathan,
> 
> Thanks for the extra info. We do indeed fork without a following exec call and
> I experimented with this preloading recently. When I experimented, I noticed
> no difference in the tracing when I preload liblttng-ust-fork.so. What exactly
> is the consequence of not doing this?

It mostly ensure that the state of lttng-ust for the child is valid and the
child will register to lttng-sessiond. It allows the child to trace between the
fork call and the exec call if any.

https://github.com/lttng/lttng-ust/blob/f596de62e69d1942ec545b8ba6b8f8b7244f8fb4/liblttng-ust/lttng-ust-comm.c#L2097

So in your case you definitely need it.

The immediate consequence is that some context information will be completely 
wrong (pid/vtid).

Mathieu Desnoyers could provide more information on the deeper side effects of
not using the fork wrapper given that no exec call is done. I'm not completely
sure of the possible side effects on the tracing buffers.

Cheers

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

Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID

[Jonathan Rajotte-Julien]

Hi Zach,

Forgot to add that you might want to look at available UST wrappers depending 
on the
nature of your daemon application.

https://lttng.org/docs/v2.10/#doc-using-lttng-ust-with-daemons
https://lttng.org/docs/v2.10/#doc-liblttng-ust-fd

Cheers
-- 
Jonathan Rajotte-Julien
EfficiOS
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH lttng-tools v3] Fix: use newly created event filter for condition check

[Jonathan Rajotte]

The following commit introduced a regression while
fixing the filter and filter_expression ownership.

commit b0a23296344e57bd2e48e62ec2d7e0d8a38661bb
Author: Jérémie Galarneau 
Date:   Sat Jan 12 14:53:56 2019 -0500

Fix: leak of filter bytecode and expression on agent event re-enable

The agent subsystem does not properly assume the clean-up of an
event's filter bytecode and expression when a previously disabled
event is re-enabled.

This change ensures that the ownership of both the filter bytecode
and expression is assumed by the agent subsystem and discarded
when a matching event is found.

Steps to reproduce the leak:
$ lttng create
$ lttng enable-event --python allo --filter 'a[42] == 241'
$ lttng disable-event --python allo
$ lttng enable-event --python allo --filter 'a[42] == 241'

Signed-off-by: Jérémie Galarneau 

Setting the "filter" object to NULL prevents the call to
add_filter_app_ctx when needed.

We use the filter from the newly created event to
perform the check and the call to add_filter_app_ctx.

Fixes coverity #1399733

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/event.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
index f32db4429..a8b7646da 100644
--- a/src/bin/lttng-sessiond/event.c
+++ b/src/bin/lttng-sessiond/event.c
@@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
created = 1;
}
 
-   if (created && filter) {
-   ret = add_filter_app_ctx(filter, filter_expression, agt);
+   if (created && aevent->filter) {
+   ret = add_filter_app_ctx(
+   aevent->filter, aevent->filter_expression, agt);
if (ret != LTTNG_OK) {
goto error;
}
-- 
2.17.1

___
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 v2] Fix: use newly created event filter for condition check

[Jonathan Rajotte-Julien]

Do not review, this include a change that should not be part of this commit.

On Tue, Sep 24, 2019 at 11:21:14AM -0400, Jonathan Rajotte wrote:
> The following commit introduced a regression while
> fixing the filter and filter_expression ownership.
> 
> commit b0a23296344e57bd2e48e62ec2d7e0d8a38661bb
> Author: Jérémie Galarneau 
> Date:   Sat Jan 12 14:53:56 2019 -0500
> 
> Fix: leak of filter bytecode and expression on agent event re-enable
> 
> The agent subsystem does not properly assume the clean-up of an
> event's filter bytecode and expression when a previously disabled
> event is re-enabled.
> 
> This change ensures that the ownership of both the filter bytecode
> and expression is assumed by the agent subsystem and discarded
> when a matching event is found.
> 
> Steps to reproduce the leak:
> $ lttng create
> $ lttng enable-event --python allo --filter 'a[42] == 241'
> $ lttng disable-event --python allo
> $ lttng enable-event --python allo --filter 'a[42] == 241'
> 
> Signed-off-by: Jérémie Galarneau 
> 
> Setting the "filter" object to NULL prevents the call to
> add_filter_app_ctx when needed.
> 
> We use the filter from the newly created event to
> perform the check and the call to add_filter_app_ctx.
> 
> Fixes coverity #1399733
> 
> Signed-off-by: Jonathan Rajotte 
> ---
>  src/bin/lttng-sessiond/agent.c | 1 +
>  src/bin/lttng-sessiond/event.c | 5 +++--
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/src/bin/lttng-sessiond/agent.c b/src/bin/lttng-sessiond/agent.c
> index 9ea899f57..79233ab7c 100644
> --- a/src/bin/lttng-sessiond/agent.c
> +++ b/src/bin/lttng-sessiond/agent.c
> @@ -1145,6 +1145,7 @@ struct agent_event *agent_create_event(const char *name,
>   event->loglevel_type = loglevel_type;
>   event->filter = filter;
>   event->filter_expression = filter_expression;
> + event->enabled = 0;
>  error:
>   return event;
>  }
> diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
> index f32db4429..a8b7646da 100644
> --- a/src/bin/lttng-sessiond/event.c
> +++ b/src/bin/lttng-sessiond/event.c
> @@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
>   created = 1;
>   }
>  
> - if (created && filter) {
> - ret = add_filter_app_ctx(filter, filter_expression, agt);
> + if (created && aevent->filter) {
> +     ret = add_filter_app_ctx(
> + aevent->filter, aevent->filter_expression, agt);
>   if (ret != LTTNG_OK) {
>   goto error;
>   }
> -- 
> 2.17.1
> 

-- 
Jonathan Rajotte-Julien
EfficiOS
___
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: use newly created event filter for condition check

[Jonathan Rajotte-Julien]

> > 4c5e3185d75ffe90b04107744693964d9051fb6b introduced a regression while
> > fixing the filter and filter_expression ownership.
> 
> What is this commit ? I'm having trouble finding it. Can you double-check and
> provide the commit Subject as well ?

Seems like I copied the parent tree commit.

See v2

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

[lttng-dev] [PATCH lttng-tools v2] Fix: use newly created event filter for condition check

[Jonathan Rajotte]

The following commit introduced a regression while
fixing the filter and filter_expression ownership.

commit b0a23296344e57bd2e48e62ec2d7e0d8a38661bb
Author: Jérémie Galarneau 
Date:   Sat Jan 12 14:53:56 2019 -0500

Fix: leak of filter bytecode and expression on agent event re-enable

The agent subsystem does not properly assume the clean-up of an
event's filter bytecode and expression when a previously disabled
event is re-enabled.

This change ensures that the ownership of both the filter bytecode
and expression is assumed by the agent subsystem and discarded
when a matching event is found.

Steps to reproduce the leak:
$ lttng create
$ lttng enable-event --python allo --filter 'a[42] == 241'
$ lttng disable-event --python allo
$ lttng enable-event --python allo --filter 'a[42] == 241'

Signed-off-by: Jérémie Galarneau 

Setting the "filter" object to NULL prevents the call to
add_filter_app_ctx when needed.

We use the filter from the newly created event to
perform the check and the call to add_filter_app_ctx.

Fixes coverity #1399733

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/agent.c | 1 +
 src/bin/lttng-sessiond/event.c | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/bin/lttng-sessiond/agent.c b/src/bin/lttng-sessiond/agent.c
index 9ea899f57..79233ab7c 100644
--- a/src/bin/lttng-sessiond/agent.c
+++ b/src/bin/lttng-sessiond/agent.c
@@ -1145,6 +1145,7 @@ struct agent_event *agent_create_event(const char *name,
event->loglevel_type = loglevel_type;
event->filter = filter;
event->filter_expression = filter_expression;
+   event->enabled = 0;
 error:
return event;
 }
diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
index f32db4429..a8b7646da 100644
--- a/src/bin/lttng-sessiond/event.c
+++ b/src/bin/lttng-sessiond/event.c
@@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
created = 1;
}
 
-   if (created && filter) {
-   ret = add_filter_app_ctx(filter, filter_expression, agt);
+   if (created && aevent->filter) {
+   ret = add_filter_app_ctx(
+   aevent->filter, aevent->filter_expression, agt);
if (ret != LTTNG_OK) {
goto error;
}
-- 
2.17.1

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

Re: [lttng-dev] Problem with application changing UID

[Jonathan Rajotte-Julien]

On Tue, Sep 24, 2019 at 02:32:41PM +, Kramer, Zach wrote:
> Hi,
> 
> Is LTTng intended to support userspace applications that change their UID at 
> run-time? As in, is there an expected behavior for when this happens?
> 
> For example:
> 
>   1.  Embedded device boots
>   2.  My daemon is launched as root via systemd
>   3.  Runs privileged code
>   4.  Changes UID to a less privileged user (500)
>   5.  Creates LTTng session
>  *   If session already exists, destroy it first
>   6.  : Destroy session
>  *   Otherwise it will be destroyed next daemon launch in step 5

When in this chain of operations is lttng-sessiond started?

> 
> [cid:image001.png@01D56F9D.AF158770]
> The logs are cleared when ‘lttng destroy sess’ is called via the LTTng C-API. 
> From my understanding, this should not happen.

I would tend to agree with you here. Would you be able to provide a small
reproducer for this? What is the version of lttng-*

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

Re: [lttng-dev] Problem with application changing UID

[Jonathan Rajotte-Julien]

Hi Zach,

Thanks for reaching out.

lttng-ust does not support the change of uid once the application is
registered to the lttng-sessiond daemon. I think that we use the uid received on
registration for all subsequent operations.

Gabriel Pollo-Guilbert actually worked on this this summer. You can check out 
the
proposed wrapper for setuid here [1]. You will need to LD_PRELOAD it on the
start of you application. It basically unregister the application and
re-register it.

[1] https://lists.lttng.org/pipermail/lttng-dev/2019-June/029035.html
 This should be applied on master of lttng-ust.
 Make sure to use lttng-tools master also. Same for lttng-modules if necessary.

Would you be interested in giving it a try?

Cheers

On Tue, Sep 24, 2019 at 02:32:41PM +, Kramer, Zach wrote:
> Hi,
> 
> Is LTTng intended to support userspace applications that change their UID at 
> run-time? As in, is there an expected behavior for when this happens?
> 
> For example:
> 
>   1.  Embedded device boots
>   2.  My daemon is launched as root via systemd
>   3.  Runs privileged code
>   4.  Changes UID to a less privileged user (500)
>   5.  Creates LTTng session
>  *   If session already exists, destroy it first
>   6.  : Destroy session
>  *   Otherwise it will be destroyed next daemon launch in step 5
> 
> This causes many conflicts with the trace folders that are created. Most of 
> the time, LTTng creates a folder + metadata for both root and the user, then 
> puts traces in the user folder. Other times, it may create a folder just for 
> the user. This is seemingly random, since it’s a fresh device boot each time. 
> If the daemon is launched directly (i.e. not from systemd), then the root 
> folder gets the traces and the user folder gets the metadata. Here is a more 
> detailed explanation:
> 
> 
> Case
> Command
> Result
> 
> Comments
> 1
> [Device boot]
> systemctl start daemon
> …../uid/500/32-bit --> has metadata and trace logs
> 
> Most times, this also happens:
> …../uid/0/32-bit --> has metadata but no trace logs
> 
> [cid:image001.png@01D56F9D.AF158770]
> Occasionally, the uid/0 folder is not created at all. This seems random, 
> since this is tested by rebooting the device several times.
> 2
> [Device boot]
> systemctl start daemon
> systemctl stop daemon
> 
>   *   This uses LTTng C-API to destroy session
> …../uid/500/32-bit --> has metadata but the logs were cleared
> 
> Most times, this also happens:
> …../uid/0/32-bit --> has metadata but no trace logs
> 
> [cid:image001.png@01D56F9D.AF158770]
> The logs are cleared when ‘lttng destroy sess’ is called via the LTTng C-API. 
> From my understanding, this should not happen.
> 
> Destroying the daemon from command line behaves properly. From my 
> understanding, this should be practically the exact same command.
> 3
> root@device: daemon
> 
> (launching via command-line)
> When daemon is killed or session is stopped: mimics case 1
> 
> When daemon is alive:
> …./uid/0/32-bit --> has trace logs but empty metadata
> 
> …./uid/500/32-bit --> has metadata but empty trace logs
> [cid:image002.png@01D56F9D.AF158770]
> 
> 
> Is this use-case supported?
> 
> Unfortunately, the logs are huge and contain sensitive information. If they 
> can help a substantial amount, I can prune them.
> 
> Thanks and best regards,
> Zach




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


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

[lttng-dev] [PATCH lttng-tools] Fix: use newly created event filter for condition check

[Jonathan Rajotte]

4c5e3185d75ffe90b04107744693964d9051fb6b introduced a regression while
fixing the filter and filter_expression ownership.

Setting the "filter" object to NULL prevents the call to
add_filter_app_ctx when needed.

We use the filter from the newly created event to
perform the check and the call to add_filter_app_ctx.

Fixes coverity #1399733

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/event.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
index f32db4429..a8b7646da 100644
--- a/src/bin/lttng-sessiond/event.c
+++ b/src/bin/lttng-sessiond/event.c
@@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
created = 1;
}
 
-   if (created && filter) {
-   ret = add_filter_app_ctx(filter, filter_expression, agt);
+   if (created && aevent->filter) {
+   ret = add_filter_app_ctx(
+   aevent->filter, aevent->filter_expression, agt);
if (ret != LTTNG_OK) {
goto error;
}
-- 
2.17.1

___
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: Free new_chunk on error

[Jonathan Rajotte-Julien]

> 
> Okai, I saw a similar pattern somewhere in the file. Might want to check if 
> the
> same can be applied there.

Nevermind it is in the release code.

> 
> > 
> > Thanks!
> > Jérémie
> > 
> > >   return NULL;
> > >  }
> > >  
> > > -- 
> > > 2.17.1
> > > 
> 
> -- 
> Jonathan Rajotte-Julien
> EfficiOS
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Jonathan Rajotte-Julien
EfficiOS
___
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: Free new_chunk on error

[Jonathan Rajotte-Julien]

On Fri, Sep 20, 2019 at 05:34:26PM -0400, Jérémie Galarneau wrote:
> Merged in master and stable-2.11.
> 
> On Fri, Sep 20, 2019 at 10:47:30AM -0400, Jonathan Rajotte wrote:
> > Fixes coverity #1405775
> > 
> > Signed-off-by: Jonathan Rajotte 
> > ---
> >  src/common/trace-chunk.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/src/common/trace-chunk.c b/src/common/trace-chunk.c
> > index 6770bd982..bad993bea 100644
> > --- a/src/common/trace-chunk.c
> > +++ b/src/common/trace-chunk.c
> > @@ -367,6 +367,8 @@ end:
> > return new_chunk;
> >  error_unlock:
> > pthread_mutex_unlock(_chunk->lock);
> > +   lttng_trace_chunk_fini(new_chunk);
> > +   free(new_chunk);
> 
> Changed this to lttng_trace_chunk_put(), which will drop the only
> existing reference to `new_chunk` and perform the equivalent
> operations to what you proposed here.

Okai, I saw a similar pattern somewhere in the file. Might want to check if the
same can be applied there.

> 
> Thanks!
> Jérémie
> 
> > return NULL;
> >  }
> >  
> > -- 
> > 2.17.1
> > 

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

[lttng-dev] [PATCH lttng-tools] Refactor: remove logically dead code

[Jonathan Rajotte]

Fixes coverity #1400681

Signed-off-by: Jonathan Rajotte 
---
 src/common/session-descriptor.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/common/session-descriptor.c b/src/common/session-descriptor.c
index 208eb46ff..713731c3e 100644
--- a/src/common/session-descriptor.c
+++ b/src/common/session-descriptor.c
@@ -550,14 +550,8 @@ lttng_session_descriptor_live_create(
struct lttng_session_descriptor_live *descriptor;
 
descriptor = _lttng_session_descriptor_live_create(name, live_timer_us);
-   if (!descriptor) {
-   goto error;
-   }
 
return descriptor ? >base : NULL;
-error:
-   lttng_session_descriptor_destroy(descriptor ? >base : NULL);
-   return NULL;
 }
 
 struct lttng_session_descriptor *
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools] Fix: Close socket handle on error

[Jonathan Rajotte]

Fixes coverity #1399739

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/client.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/bin/lttng-sessiond/client.c b/src/bin/lttng-sessiond/client.c
index 956dab8c8..870277534 100644
--- a/src/bin/lttng-sessiond/client.c
+++ b/src/bin/lttng-sessiond/client.c
@@ -1985,8 +1985,11 @@ static int create_client_sock(void)
/* File permission MUST be 660 */
ret = chmod(config.client_unix_sock_path.value, S_IRUSR | S_IWUSR | 
S_IRGRP | S_IWGRP);
if (ret < 0) {
-   ERR("Set file permissions failed: %s", 
config.client_unix_sock_path.value);
+   ERR("Set file permissions failed: %s",
+   config.client_unix_sock_path.value);
PERROR("chmod");
+   (void) lttcomm_close_unix_sock(client_sock);
+   ret = -1;
goto end;
}
DBG("Created client socket (fd = %i)", client_sock);
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools] Fix: Null check before destroying health_sessiond

[Jonathan Rajotte]

Fixes coverity #1399735

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/bin/lttng-sessiond/main.c b/src/bin/lttng-sessiond/main.c
index 5f99bdbf6..a428630f8 100644
--- a/src/bin/lttng-sessiond/main.c
+++ b/src/bin/lttng-sessiond/main.c
@@ -1819,7 +1819,9 @@ stop_threads:
lttng_pipe_destroy(ust64_channel_monitor_pipe);
lttng_pipe_destroy(kernel_channel_monitor_pipe);
 
-   health_app_destroy(health_sessiond);
+   if (health_sessiond) {
+   health_app_destroy(health_sessiond);
+   }
 exit_create_run_as_worker_cleanup:
 exit_options:
sessiond_cleanup_lock_file();
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools] Fix: Move initialization of queue_pipe_fd after null check of handle

[Jonathan Rajotte]

Fixes coverity #1399732

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/rotation-thread.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/bin/lttng-sessiond/rotation-thread.c 
b/src/bin/lttng-sessiond/rotation-thread.c
index 7bd6c6819..1ee3974f0 100644
--- a/src/bin/lttng-sessiond/rotation-thread.c
+++ b/src/bin/lttng-sessiond/rotation-thread.c
@@ -832,8 +832,6 @@ void *thread_rotation(void *data)
int ret;
struct rotation_thread_handle *handle = data;
struct rotation_thread thread;
-   const int queue_pipe_fd = lttng_pipe_get_readfd(
-   handle->rotation_timer_queue->event_pipe);
 
DBG("[rotation-thread] Started rotation thread");
 
@@ -842,6 +840,10 @@ void *thread_rotation(void *data)
goto end;
}
 
+   /* Must be after null checking of handle for const assignment */
+   const int queue_pipe_fd = lttng_pipe_get_readfd(
+   handle->rotation_timer_queue->event_pipe);
+
rcu_register_thread();
rcu_thread_online();
 
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools] Fix: Free new_chunk on error

[Jonathan Rajotte]

Fixes coverity #1405775

Signed-off-by: Jonathan Rajotte 
---
 src/common/trace-chunk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/common/trace-chunk.c b/src/common/trace-chunk.c
index 6770bd982..bad993bea 100644
--- a/src/common/trace-chunk.c
+++ b/src/common/trace-chunk.c
@@ -367,6 +367,8 @@ end:
return new_chunk;
 error_unlock:
pthread_mutex_unlock(_chunk->lock);
+   lttng_trace_chunk_fini(new_chunk);
+   free(new_chunk);
return NULL;
 }
 
-- 
2.17.1

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

Re: [lttng-dev] Python CTF writer example

[Jonathan Rajotte-Julien]

Hi,

On Fri, Sep 13, 2019 at 07:03:59PM -0400, Francis Giraldeau wrote:
> Hello!
> 
> It looks like there are some issues with the Python CTF writer example with
> babeltrace stable-1.5.

I will infer that you are looking at this doc:

  https://diamon.org/babeltrace/docs/python/examples/#ctf-writer-api-examples

This doc is currently outdated(invalid). We are in the process of
revamping it/removing it.

If you need an example for bt 1.5 use:

  
https://github.com/efficios/babeltrace/blob/stable-1.5/bindings/python/babeltrace/examples/ctf_writer.py

This example works as expected.

> 
> * Import error, should replace "import babeltrace.writer as btw" by "from
> babeltrace import CTFWriter as btw"
> * The FloatingPointDeclaration does not exists and should be replaced
> by FloatFieldDeclaration
> * babeltrace.common.CTFStringEncoding.UTF8 is
> instead babeltrace.CTFStringEncoding.UTF8
> * The variant still had issue that I cannot fix (ValueError("Invalid tag
> provided.") babeltrace.py:2221)

If you still wish to follow the documentation, please make sure to read the
green notice here:
  https://diamon.org/babeltrace/docs/python/examples/#examples

> 
> Events with simple fields are working okay with these changes. I thought
> that the clock would be updated automatically when appending the event, but
> that would be nice also to add it to the example.
> 
> I tried babeltrace 2.0.0-pre6, but the writer API seems to have
> disappeared. I was looking at how to create a ctf.fs.sink, but I was not
> successful. Is writing CTF traces with the Python bindings still possible?

The ctf-writer capability are not part of the bindings anymore.
 https://review.lttng.org/c/babeltrace/+/1392

What can be done is writing a source plugin using the bindings and use a ctf
sink on the cli to generate a ctf trace.

A quick source plugin: http://paste.ubuntu.com/p/8CBqTt8cSj/

Note that babeltrace 1.5 and babeltrace 2 can coexist on the same system.
Allowing you to still use the bindings from bt1.5 to generate traces.

I recommend that you stick with the babeltrace 1.5 bindings (import babeltrace).

Cheers

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

Re: [lttng-dev] tracepoint_enabled returns true for disabled provider, event

[Jonathan Rajotte-Julien]

Hi,

In the end this was a problem involving automatic session creation
(configuration) behind the back of Anders.

A "lttng list" helped figure out the problem.

lttng behave as expected.

Cheers

On Sat, Sep 07, 2019 at 02:42:22PM +0200, Anders Johansson wrote:
> Hi
> 
> I troubleshooting a huge application where i experience the problem that
> even if tracepoint_enabled is used i get the huge overhead of formatting
> the output even if then the message is not sent to the lttng buffers.
> 
> The tracepoint loglevel is set to TRACE_INFO using the TRACEPOINT_LOGLEVEL
> macro. I managed to rebuild the application setting the level to
> TRACE_DEBUG instead and then i could print continuously that the
> tracepoint_enabled returned false. If i flip it back to TRACE_INFO
> tracepoint_enabled always returns true, hence do lots of string building
> but then no trace is actually sent off to lttng (which is correct since i
> haven't enabled the tracepoint). Even if i explicitly do disable event on
> the provider and tracepoint the TRACE_INFO tracepoints returns true in
> tracepoint_enabled
> 
> Is this by design that tracepoint_enabled always returns true for
> TRACE_INFO and lower values or is this configurable in any way?
> 
> I am using this inside a docker image running Wind River Linux
> bash-4.3# lttng --version
> lttng (LTTng Trace Control) 2.10.6 - KeKriek - v2.10.6-11-g8fcbf96
> bash-4.3#
> 
> Any advice are welcome!
> //Anders

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


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

Re: [lttng-dev] Kernel tracer not available with lttng compiled in

[Jonathan Rajotte-Julien]

Hi,

We will need more information.

What version of lttng are we speaking of here?

What kernel version/tree?

Exactly how did you build your kernel with lttng-modules built-in?

Did you follow this?:

  
https://github.com/lttng/lttng-modules/blob/master/README.md#kernel-built-in-support

Cheers

On Thu, Sep 05, 2019 at 12:23:40PM +, Kjeld Flarup via lttng-dev wrote:
> Hello 
> 
> I'm trying to get lttng working on an Power PC board
> 
> 
> ~ # lttng create my-kernel-session --output=/tmp/my-kernel-trace
> Spawning a session daemon
> Session my-kernel-session created.
> Traces will be written in /tmp/my-kernel-trace
> ~ # lttng list --kernel
> Error: Unable to list kernel events: Kernel tracer not available
> Error: Command error
> 
> Now ALL that I can find when googling this error is that the kernel modules 
> is not loaded. 
> However I'm not using modules, but compile everything in. 
> 
> Here is a small extract of what is enabled in my kernel. I have attached the 
> full /proc/config.gz
> Am I missing something?
> 
> CONFIG_NOP_TRACER=y
> CONFIG_HAVE_FUNCTION_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> CONFIG_TRACER_MAX_TRACE=y
> CONFIG_CONTEXT_SWITCH_TRACER=y
> CONFIG_GENERIC_TRACER=y
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=y
> CONFIG_IRQSOFF_TRACER=y
> CONFIG_PREEMPT_TRACER=y
> CONFIG_SCHED_TRACER=y
> # CONFIG_HWLAT_TRACER is not set
> CONFIG_TRACER_SNAPSHOT=y
> CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
> # CONFIG_STACK_TRACER is not set
> 
> CONFIG_HAVE_KPROBES_ON_FTRACE=y
> CONFIG_HAVE_DYNAMIC_FTRACE=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> CONFIG_FTRACE=y
> CONFIG_FTRACE_SYSCALLS=y
> CONFIG_DYNAMIC_FTRACE=y
> CONFIG_FTRACE_MCOUNT_RECORD=y
> # CONFIG_FTRACE_STARTUP_TEST is not set
> 
> 
> CONFIG_EVENT_TRACING=y
> CONFIG_PERF_EVENTS=y
> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> 
> CONFIG_KRETPROBES=y
> 
> CONFIG_HIGH_RES_TIMERS=y
> CONFIG_TRACEPOINTS=y
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> # CONFIG_TRACE_SINK is not set
> CONFIG_TRACE_IRQFLAGS=y
> CONFIG_TRACE_CLOCK=y
> CONFIG_TRACE_PREEMPT_TOGGLE=y
> CONFIG_TRACER_SNAPSHOT=y
> CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
> # CONFIG_TRACEPOINT_BENCHMARK is not set
> # CONFIG_TRACE_EVAL_MAP_FILE is not set
> CONFIG_KALLSYMS=y
> # CONFIG_KALLSYMS_ALL is not set
> CONFIG_KALLSYMS_BASE_RELATIVE=y
> 
> 
> 
> Regards
> Kjeld Flarup
> DEIF A/S, R Platform Software
> 
> 


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


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

Re: [lttng-dev] Problem with vpid in lttng output

[Jonathan Rajotte-Julien]

Hi,

Note that the restriction to prevent an add-context command on a
started session is not present in 2.10.2. It is present starting at 2.10.3.

 joraj@~/lttng/stable-2.10/lttng-tools [(v2.10.7)][]$ git tag --contains 
3aaf55eaa5aee2db6e2a1a46685e45f2395fc15b
 v2.10.3
 v2.10.4
 v2.10.5
 v2.10.6
 v2.10.7

This would explain why you can issue the commands in the order you are issuing
them currently (add-context after start).

 lttng create csim_session_rpup -o /tmp/csim_session_rpup
 lttng enable-event -u
 lttng start csim_session_rpup
 lttng add-context -u -t vpid
 lttng track -u -s csim_session_rpup --all

To comply with this without upgrading, you can swap the order of the add-context
and start command.

commands:

 lttng create
 lttng enable-event -u ...
 lttng add-context -u -t vpid
 lttng start
 lttng track ...

I did some experiment using v2.10.2 to reproduce the issue.
I used the same sequence of commands you provided:

 lttng create csim_session_rpup -o /tmp/csim_session_rpup
 lttng enable-event -u
 lttng start csim_session_rpup
 lttng add-context -u -t vpid
 lttng track -u -s csim_session_rpup --all

At first, I tried a scenario where the only instrumented (registered) app is run
after the add-context. No other instrumented apps were running at the moment the
"lttng start" was issued. The trace produced contained the vpid context.

What happen if an instrumented app is already running when the "lttng start"
command is issued? The "lttng add-context" does not report any problem yet the
resulting trace does not contain any vpid context.

In the lttng-sessiond logs we see that the add-context command failed for the 
app:

  DEBUG2 - 11:19:43.718781 [9499/9506]: UST app adding context to channel 
channel0 (in create_ust_app_channel_context() at ust-app.c:2357)
  DEBUG3 - 11:19:43.718784 [9499/9506]: UST app context 1 allocated (in 
alloc_ust_app_ctx() at ust-app.c:1146)
  Error: UST app create channel context failed for app (pid: 7350) with ret 
-1028
  Error: Failed to add context to channel channel0

The first scenario works because we delay the setup of the channel until an app
eligible for tracing is present.

That should be it.

Cheers

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

Re: [lttng-dev] Problem with vpid in lttng output

[Jonathan Rajotte-Julien]

Hi Aleksander,

On Mon, Sep 02, 2019 at 12:01:46PM +, Aleksander Twardowski via lttng-dev 
wrote:
> Hi,
> 
> I do not know if I am addressing problem correctly but let’s try 
> I have a problem, occurring very rarely, with vpid in lttng output.
> Sometimes, I do not know why, vpid is not visible.
> 
> Proper lttng log:
> [14:08:35.156333670] (+0.10724) selilsx1795 com_ericsson_csim_up:ERROR: { 
> cpu_id = 0 }, { vpid = 16826 }, { src = 
> "/home/ealetwa/repos/bpu-up/src/Rpup.cpp:125:", obj = "GENERAL", msg = 
> "Failed to initialize SDS connection" }

Side note: make sure to redact information that could be sensitive. Here the
payload and event name could be considered sensitive. It is up to you to
evaluate what is sensitive and what is not.

> 
> Problematic lttng log:
> “[14:08:35.156333670] (+0.10724) selilsx1795 com_ericsson_csim_up:ERROR: 
> { cpu_id = 0 }, { src = "/home/ealetwa/repos/bpu-up/src/Rpup.cpp:125:", obj = 
> "GENERAL", msg = "Failed to initialize SDS connection" }”

Does this situation happen inside the same trace? Or does it seems to happens
between traces?

> 
> If you can help me, tell me in which cases this problem occurring that would 
> be great.

We are not aware of any ongoing issue with the context subsystem. A first step
would be to validate that the "lttng add-context" (or equivalent) was performed
without any error for the session of the trace with the vpid information
missing. Note that you cannot add context field for a tracing session if it was
started at least once.

Cheers

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

[lttng-dev] [PATCH lttng-tools v2] Fix: check validity of a stream before invoking ust flush command

[Jonathan Rajotte]

At the time ustctl_flush_buffer is called the ustream object might have
already been freed on lttng-ust side.

This can happen following a lttng_consumer_cleanup_relayd and concurrent
consumer flush command (lttng stop).

The chain of events goes as follows.

An error on communication with lttng-relayd occurs.
lttng_consumer_cleanup_relayd flags the streams for deletion
(CONSUMER_ENDPOINT_INACTIVE). validate_endpoint_status_data_stream calls
consumer_del_stream.

At the same time the hash table of streams is iterated over in the
flush_channel function following a stop command. The loop is iterating on
a given stream. The current thread is unscheduled before taking the stream
lock.

In the initial thread, the same stream is the current iteration of
cds_lfht_for_each_entry in validate_endpoint_status_data_stream.

consumer_del_stream is called on it. The stream lock is acquired, and
destroy_close_stream is called. lttng_ustconsumer_del_stream is eventually
called and at this point the ustream is freed.

Going back to the iteration in flush_channel. The current stream is still
valid from the point of view of the iteration, ustctl_flush_buffer is then
called on a freed ustream object.

This can lead to unknown behaviour since there is no validation on the
lttng-ust side. The underlying memory of the ustream object is garbage at
this point.

To prevent such scenario, we check for the presence of the node in the
hash table via cds_lfht_is_node_deleted while holding the stream lock.
This is valid because the stream destruction removes the node from
the hash table and frees the ustream object with the stream lock held.

This duplicate similar "validation" check of the stream object. [1][2]

[1] src/common/consumer/consumer.c:consumer_close_channel_streams
[2] src/common/ust-consumer/ust-consumer.c:close_metadata

This issue can be reproduced by the following scenario:

Modify flush_channel to sleep (i.e 10s) before acquiring the lock on
a stream.

Modify lttng-ust ustctl_destroy_stream to set the
ring_buffer_clock_read callback to NULL.
  Note: An assert on !cds_lfht_is_node_deleted in flush channel
  after acquiring the lock can provide the same information. We are
  modifying the callback to simulate the original backtrace from our
  customer.

lttng-relayd
lttng-sessiond
lttng create --live
lttng enable-event -u -a
lttng start
Start some applications to generate data.
lttng stop
  The stop command force a flush of the channel/streams.
pkill -9 lttng-relayd
Expect assert or segfault

The original customer backtrace:

  0  lib_ring_buffer_try_switch_slow (handle=, tsc=, offsets=0x3fffa9b76c80, chan=0x3fff98006e90, buf=,
 mode=) at 
/usr/src/debug/lttng-ust/2.9.1/git/libringbuffer/ring_buffer_frontend.c:1834
  1  lib_ring_buffer_switch_slow (buf=0x3fff98016b40, mode=, 
handle=0x3fff98017670)
 at 
/usr/src/debug/lttng-ust/2.9.1/git/libringbuffer/ring_buffer_frontend.c:1952
  2  0x3fffac680940 in ustctl_flush_buffer (stream=, 
producer_active=)
 at /usr/src/debug/lttng-ust/2.9.1/git/liblttng-ust-ctl/ustctl.c:1568
  3  0x10031bc8 in flush_channel (chan_key=) at 
ust-consumer.c:772
  4  lttng_ustconsumer_recv_cmd (ctx=, sock=, 
consumer_sockpoll=) at ust-consumer.c:1651
  5  0x1000de50 in lttng_consumer_recv_cmd (ctx=, 
sock=, consumer_sockpoll=) at consumer.c:2011
  6  0x10014208 in consumer_thread_sessiond_poll (data=0x10079430) at 
consumer.c:3192
  7  0x3fffac608b30 in start_thread (arg=0x3fffa9b7bdb0) at 
pthread_create.c:462
  8  0x3fffac530d0c in .__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:96

Reviewed-by: Mathieu Desnoyers 
Signed-off-by: Jonathan Rajotte 
---
 src/common/ust-consumer/ust-consumer.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/common/ust-consumer/ust-consumer.c 
b/src/common/ust-consumer/ust-consumer.c
index 94b761cb8..f2e62d0ee 100644
--- a/src/common/ust-consumer/ust-consumer.c
+++ b/src/common/ust-consumer/ust-consumer.c
@@ -764,10 +764,19 @@ static int flush_channel(uint64_t chan_key)
health_code_update();
 
pthread_mutex_lock(>lock);
+
+   /*
+* Protect against concurrent teardown of a stream.
+*/
+   if (cds_lfht_is_node_deleted(>node.node)) {
+   goto next;
+   }
+
if (!stream->quiescent) {
ustctl_flush_buffer(stream->ustream, 0);
stream->quiescent = true;
}
+next:
pthread_mutex_unlock(>lock);
}
 error:
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools] Fix: check validity of a stream before invoking ust flush command

[Jonathan Rajotte]

At the time ustctl_flush_buffer is called the ustream object might have
already been freed on lttng-ust side.

This can happen following a lttng_consumer_cleanup_relayd and concurrent
consumer flush command (lttng stop).

The train of events goes as follows.

An error on communication with lttng-relayd occurs.
lttng_consumer_cleanup_relayd flags the streams for deletion
(CONSUMER_ENDPOINT_INACTIVE). validate_endpoint_status_data_stream calls
consumer_del_stream.

At the same time the hash table of streams is iterated over in the
flush_channel function following a stop command. The loop is iterating on
a given stream. The current thread is unscheduled before taking the stream
lock.

In the initial thread, the same stream is the current iteration of
cds_lfht_for_each_entry in validate_endpoint_status_data_stream.

consumer_del_stream is called on it. The stream lock is acquired, and
destroy_close_stream is called. lttng_ustconsumer_del_stream is eventually
called and at this point the ustream is freed.

Going back to the iteration in flush_channel. The current stream is still
valid from the point of view of the iteration, ustctl_flush_buffer is then
called on a freed ustream object.

This can lead to unknown behaviour since there is no validation on
lttng-ust side. The underlying memory of the ustream object is garbage at
this point.

To prevent such scenario, we check for the presence of the node in the
hash table via cds_lfht_is_node_deleted. This is valid because the node is
removed from the hash table before deleting the ustream object on
lttng-ust side. The removal from the hash table also requires the stream
lock ensuring the validity of cds_lfht_is_node_deleted return value.

This duplicate similar "validation" check of the stream object. [1][2]

[1] src/common/consumer/consumer.c:consumer_close_channel_streams
[2] src/common/ust-consumer/ust-consumer.c:close_metadata

This issue can be reproduced by the following scenario:

Modify flush_channel to sleep (i.e 10s) before acquiring the lock on
a stream.

Modify lttng-ust ustctl_destroy_stream to set the
ring_buffer_clock_read callback to NULL.
  Note: An assert on !cds_lfht_is_node_deleted in flush channel
  after acquiring the lock can provide the same information. We are
  modifying the callback to simulate the original backtrace from our
  customer.

lttng-relayd
lttng-sessiond
lttng create --live
lttng enable-event -u -a
lttng start
Start some applications to generate data.
lttng stop
  The stop command force a flush of the channel/streams.
pkill -9 lttng-relayd
Expect assert or segfault

The original customer backtrace:

  0  lib_ring_buffer_try_switch_slow (handle=, tsc=, offsets=0x3fffa9b76c80, chan=0x3fff98006e90, buf=,
 mode=) at 
/usr/src/debug/lttng-ust/2.9.1/git/libringbuffer/ring_buffer_frontend.c:1834
  1  lib_ring_buffer_switch_slow (buf=0x3fff98016b40, mode=, 
handle=0x3fff98017670)
 at 
/usr/src/debug/lttng-ust/2.9.1/git/libringbuffer/ring_buffer_frontend.c:1952
  2  0x3fffac680940 in ustctl_flush_buffer (stream=, 
producer_active=)
 at /usr/src/debug/lttng-ust/2.9.1/git/liblttng-ust-ctl/ustctl.c:1568
  3  0x10031bc8 in flush_channel (chan_key=) at 
ust-consumer.c:772
  4  lttng_ustconsumer_recv_cmd (ctx=, sock=, 
consumer_sockpoll=) at ust-consumer.c:1651
  5  0x1000de50 in lttng_consumer_recv_cmd (ctx=, 
sock=, consumer_sockpoll=) at consumer.c:2011
  6  0x10014208 in consumer_thread_sessiond_poll (data=0x10079430) at 
consumer.c:3192
  7  0x3fffac608b30 in start_thread (arg=0x3fffa9b7bdb0) at 
pthread_create.c:462
  8  0x3fffac530d0c in .__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:96

Signed-off-by: Jonathan Rajotte 
---
 src/common/ust-consumer/ust-consumer.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/common/ust-consumer/ust-consumer.c 
b/src/common/ust-consumer/ust-consumer.c
index 94b761cb8..f2e62d0ee 100644
--- a/src/common/ust-consumer/ust-consumer.c
+++ b/src/common/ust-consumer/ust-consumer.c
@@ -764,10 +764,19 @@ static int flush_channel(uint64_t chan_key)
health_code_update();
 
pthread_mutex_lock(>lock);
+
+   /*
+* Protect against concurrent teardown of a stream.
+*/
+   if (cds_lfht_is_node_deleted(>node.node)) {
+   goto next;
+   }
+
if (!stream->quiescent) {
ustctl_flush_buffer(stream->ustream, 0);
stream->quiescent = true;
}
+next:
pthread_mutex_unlock(>lock);
}
 error:
-- 
2.17.1

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

Re: [lttng-dev] 回复:Re: 回复:Re: 回复:Re: Pros and Cons of LTTng

[Jonathan Rajotte-Julien]

Hi Hai,

Sorry for the delay.

The main obstruction to kernel tracing support for RHEL6 is indeed the kernel.

Note that we dropped the patches in the master branch:

  commit ca2fca6b64297227b2565773a495803aa90c148e
  Author: Michael Jeanson 
  Date:   Thu Nov 8 15:24:01 2018 -0500

  Drop compat patches for kernels < 2.6.36

  Signed-off-by: Michael Jeanson 
  Signed-off-by: Mathieu Desnoyers 

Still, the stable 2.10 branch still carries the patches that you would need [1].
As previously mentioned, those patches might not apply cleanly since it has
been a while any effort was put in testing against RHEL6.

[1] https://github.com/lttng/lttng-modules/tree/stable-2.10/linux-patches

Cheers

On Fri, Aug 09, 2019 at 07:44:57AM +0800, 杨海 wrote:
> Hi Mathieu,
> 
> We aim to trace SYSCALL in kernel space. In general, what would be the 
> obstacles to support RHEL6? Or what are key kernel patches to be necessary? 
> 
> 
> Regards
> Hai 
> 
> 
> 
> 
> 
> 
> 
> --原始邮件--
> 发件人："Mathieu Desnoyers ";
> 发送时间：2019年7月30日(星期二) 晚上10:04
> 收件人："杨海" ;
> 抄送："Jonathan Rajotte ";"lttng-dev 
> ";
> 主题：Re: [lttng-dev] 回复:Re:  回复:Re:  Pros and Cons of LTTng
> ---
> 
>  Hi,
> 
> 
> 
> The current LTTng kernel tracer (lttng-modules) supports Linux 3.0+ only.
> 
> 
> 
> If you only need to trace user-space, you might be able to use lttng-tools 
> and lttng-ust
> 
> on an older kernel. Please refer to the README.md files of each project for 
> information
> 
> about their environment prerequisites.
> 
> 
> 
> The RHEL6 kernel variant based on 2.6.32-2.6.35 Linux kernels has never been 
> supported by
> 
> the LTTng 2.x kernel tracers without kernel patching.
> 
> 
> 
> Thanks,
> 
> 
> 
> Mathieu
> 
> 
> 
> - On Jul 29, 2019, at 8:34 PM, 杨海  wrote:
> 
> Hi Mathieu,
> Thanks. I am looking for packages for older distributions like CentOS 6 (with 
> kernel 2.6) but could not find it. And which kernel version is minimum 
> requirement for LTTng?
> 
> Regards
> Hai
> 
> 
> 
> 
> 
> -- Original --
> From:  "Mathieu Desnoyers";
> Date:  Thu, Jul 25, 2019 11:48 PM
> To:  "杨海"; 
> Cc:  "Jonathan Rajotte"; 
> "lttng-dev"; 
> Subject:  Re: [lttng-dev] 回复:Re:  回复:Re:  Pros and Cons of LTTng
> 
>  
> - On Jul 25, 2019, at 4:21 PM, 杨海  wrote:
> 
> Hi
> 
> Thanks for quick response. 
> LTTng is really impressive on performance，especially under heavy workload. 
> When using it on critical machines，stability is also essential. 
> I wonder how LTTng is commercialized and any products or OS distributions 
> already enabled it. 
> I took a look at lttng-modules bug list，there are a few kernel oops years ago 
> and got resolved. May I say it is very stable or it has not been fully 
> tested? 
> 
> Hi,
> 
> 
> EfficiOS has had commercial customers using LTTng in production for many 
> years now.
> LTTng per-se is distributed as packages in all major Linux distributions. 
> EfficiOS also provides
> 
> more up-to-date packages for some distributions through 
> http://packages.efficios.com/
> 
> 
> The way we commercialize LTTng is through funding for design and 
> implementation of
> customer's feature requests. We also provide commercial support tailored to 
> specific
> customer's environments, which includes SLA and continuous integration 
> testing of specific
> environments.
> 
> 
> If those are services you are interested in, please feel free to contact us 
> in private so we
> can further discuss your needs.
> 
> 
> Best regards,
> 
> 
> Mathieu
> 
> 
> regards
> Hai
> 
> 
> 
> 
> 
> 
> --原始邮件--
> 发件人："Jonathan Rajotte-Julien ";
> 发送时间：2019年7月23日(星期二) 上午6:20
> 收件人："杨海" ;
> 抄送："lttng-dev ";
> 主题：Re:  回复:Re: [lttng-dev] Pros and Cons of LTTng
> ---
> 
>  Hi,
> 
> > As to LD_PRELOAD, it is also used for privilege escalation. Will it be 
> > regarded as vulnerability and forbidden on some Linux systems?
> 
> It could yes.
> In that case you will be limited to the syscalls interface for the libc
> observability unless you instrument it and distribute it.
> 
> Cheers.
> 
> 
> 
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 
> 
> -- 
> 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 
>  
> 
> 
> 
> 
> 
> 
> -- 
> 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

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

[lttng-dev] [PATCH lttng-tools v2 4/4] Support LTTNG_KERNEL_SESSION_SET_CREATION_DATETIME of lttng-modules

[Jonathan Rajotte]

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/kernel.c  |  6 ++
 src/common/kernel-ctl/kernel-ctl.c   | 15 +++
 src/common/kernel-ctl/kernel-ctl.h   |  1 +
 src/common/kernel-ctl/kernel-ioctl.h |  2 ++
 src/common/lttng-kernel.h|  8 
 5 files changed, 32 insertions(+)

diff --git a/src/bin/lttng-sessiond/kernel.c b/src/bin/lttng-sessiond/kernel.c
index 7793ba6bc..cedb9346c 100644
--- a/src/bin/lttng-sessiond/kernel.c
+++ b/src/bin/lttng-sessiond/kernel.c
@@ -139,6 +139,12 @@ int kernel_create_session(struct ltt_session *session, int 
tracer_fd)
session->id, session->name);
}
 
+   ret = kernctl_session_set_creation_time(lks->fd, 
session->creation_time);
+   if (ret) {
+   WARN("Could not set kernel session creation time for session %" 
PRIu64 " name: %s",
+   session->id, session->name);
+   }
+
return 0;
 
 error:
diff --git a/src/common/kernel-ctl/kernel-ctl.c 
b/src/common/kernel-ctl/kernel-ctl.c
index 6a37015ae..8c0025c93 100644
--- a/src/common/kernel-ctl/kernel-ctl.c
+++ b/src/common/kernel-ctl/kernel-ctl.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "kernel-ctl.h"
 #include "kernel-ioctl.h"
@@ -248,6 +249,20 @@ int kernctl_session_set_name(int fd, const char *name)
_name);
 }
 
+int kernctl_session_set_creation_time(int fd, time_t time)
+{
+   int ret;
+   struct lttng_kernel_session_creation_time creation_time;
+
+   ret = time_t_to_ISO8601(creation_time.iso8601, 
sizeof(creation_time.iso8601), time);
+   if (ret) {
+   return -1;
+   }
+
+   return LTTNG_IOCTL_CHECK(fd, LTTNG_KERNEL_SESSION_SET_CREATION_TIME,
+   _time);
+}
+
 int kernctl_create_stream(int fd)
 {
return compat_ioctl_no_arg(fd, LTTNG_KERNEL_OLD_STREAM,
diff --git a/src/common/kernel-ctl/kernel-ctl.h 
b/src/common/kernel-ctl/kernel-ctl.h
index 884929ac1..053e7df63 100644
--- a/src/common/kernel-ctl/kernel-ctl.h
+++ b/src/common/kernel-ctl/kernel-ctl.h
@@ -68,6 +68,7 @@ int kernctl_list_tracker_pids(int fd);
 int kernctl_session_regenerate_metadata(int fd);
 int kernctl_session_regenerate_statedump(int fd);
 int kernctl_session_set_name(int fd, const char *name);
+int kernctl_session_set_creation_time(int fd, time_t time);
 
 /* Buffer operations */
 
diff --git a/src/common/kernel-ctl/kernel-ioctl.h 
b/src/common/kernel-ctl/kernel-ioctl.h
index ce910e96f..8d39abbe3 100644
--- a/src/common/kernel-ctl/kernel-ioctl.h
+++ b/src/common/kernel-ctl/kernel-ioctl.h
@@ -147,6 +147,8 @@
 #define LTTNG_KERNEL_SESSION_STATEDUMP _IO(0xF6, 0x5C)
 #define LTTNG_KERNEL_SESSION_SET_NAME  \
_IOR(0xF6, 0x5D, struct lttng_kernel_session_name)
+#define LTTNG_KERNEL_SESSION_SET_CREATION_TIME \
+   _IOR(0xF6, 0x5E, struct lttng_kernel_session_creation_time)
 
 /* Channel FD ioctl */
 #define LTTNG_KERNEL_STREAM_IO(0xF6, 0x62)
diff --git a/src/common/lttng-kernel.h b/src/common/lttng-kernel.h
index 001a16e2d..2fd14dc1e 100644
--- a/src/common/lttng-kernel.h
+++ b/src/common/lttng-kernel.h
@@ -28,6 +28,7 @@
 #define LTTNG_KERNEL_SYM_NAME_LEN  256
 #define LTTNG_KERNEL_MAX_UPROBE_NUM  32
 #define LTTNG_KERNEL_SESSION_NAME_LEN  256
+#define LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN 26
 
 /*
  * LTTng DebugFS ABI structures.
@@ -186,4 +187,11 @@ struct lttng_kernel_session_name {
char name[LTTNG_KERNEL_SESSION_NAME_LEN];
 } LTTNG_PACKED;
 
+/*
+ * kernel session creation datetime
+ */
+struct lttng_kernel_session_creation_time {
+   char iso8601[LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN];
+} LTTNG_PACKED;
+
 #endif /* _LTTNG_KERNEL_H */
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools v2 3/4] Support LTTNG_KERNEL_SESSION_SET_NAME of lttng-modules

[Jonathan Rajotte]

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/kernel.c  | 14 ++
 src/common/kernel-ctl/kernel-ctl.c   | 10 ++
 src/common/kernel-ctl/kernel-ctl.h   |  1 +
 src/common/kernel-ctl/kernel-ioctl.h |  2 ++
 src/common/lttng-kernel.h|  8 
 5 files changed, 35 insertions(+)

diff --git a/src/bin/lttng-sessiond/kernel.c b/src/bin/lttng-sessiond/kernel.c
index b4fc995ce..7793ba6bc 100644
--- a/src/bin/lttng-sessiond/kernel.c
+++ b/src/bin/lttng-sessiond/kernel.c
@@ -125,6 +125,20 @@ int kernel_create_session(struct ltt_session *session, int 
tracer_fd)
 
DBG("Kernel session created (fd: %d)", lks->fd);
 
+   /*
+* This is necessary since the creation time is present in the session
+* name when it is generated.
+*/
+   if (session->has_auto_generated_name) {
+   ret = kernctl_session_set_name(lks->fd, DEFAULT_SESSION_NAME);
+   } else {
+   ret = kernctl_session_set_name(lks->fd, session->name);
+   }
+   if (ret) {
+   WARN("Could not set kernel session name for session %" PRIu64 " 
name: %s",
+   session->id, session->name);
+   }
+
return 0;
 
 error:
diff --git a/src/common/kernel-ctl/kernel-ctl.c 
b/src/common/kernel-ctl/kernel-ctl.c
index 047d40a34..6a37015ae 100644
--- a/src/common/kernel-ctl/kernel-ctl.c
+++ b/src/common/kernel-ctl/kernel-ctl.c
@@ -238,6 +238,16 @@ int kernctl_session_regenerate_statedump(int fd)
return LTTNG_IOCTL_CHECK(fd, LTTNG_KERNEL_SESSION_STATEDUMP);
 }
 
+int kernctl_session_set_name(int fd, const char *name)
+{
+   struct lttng_kernel_session_name session_name;
+
+   strncpy(session_name.name, name, LTTNG_KERNEL_SESSION_NAME_LEN);
+
+   return LTTNG_IOCTL_CHECK(fd, LTTNG_KERNEL_SESSION_SET_NAME,
+   _name);
+}
+
 int kernctl_create_stream(int fd)
 {
return compat_ioctl_no_arg(fd, LTTNG_KERNEL_OLD_STREAM,
diff --git a/src/common/kernel-ctl/kernel-ctl.h 
b/src/common/kernel-ctl/kernel-ctl.h
index 841c31da0..884929ac1 100644
--- a/src/common/kernel-ctl/kernel-ctl.h
+++ b/src/common/kernel-ctl/kernel-ctl.h
@@ -67,6 +67,7 @@ int kernctl_list_tracker_pids(int fd);
 
 int kernctl_session_regenerate_metadata(int fd);
 int kernctl_session_regenerate_statedump(int fd);
+int kernctl_session_set_name(int fd, const char *name);
 
 /* Buffer operations */
 
diff --git a/src/common/kernel-ctl/kernel-ioctl.h 
b/src/common/kernel-ctl/kernel-ioctl.h
index e7ff50b24..ce910e96f 100644
--- a/src/common/kernel-ctl/kernel-ioctl.h
+++ b/src/common/kernel-ctl/kernel-ioctl.h
@@ -145,6 +145,8 @@
 #define LTTNG_KERNEL_SESSION_METADATA_REGEN_IO(0xF6, 0x59)
 /* 0x5A and 0x5B are reserved for a future ABI-breaking cleanup. */
 #define LTTNG_KERNEL_SESSION_STATEDUMP _IO(0xF6, 0x5C)
+#define LTTNG_KERNEL_SESSION_SET_NAME  \
+   _IOR(0xF6, 0x5D, struct lttng_kernel_session_name)
 
 /* Channel FD ioctl */
 #define LTTNG_KERNEL_STREAM_IO(0xF6, 0x62)
diff --git a/src/common/lttng-kernel.h b/src/common/lttng-kernel.h
index cd1a15f67..001a16e2d 100644
--- a/src/common/lttng-kernel.h
+++ b/src/common/lttng-kernel.h
@@ -27,6 +27,7 @@
 
 #define LTTNG_KERNEL_SYM_NAME_LEN  256
 #define LTTNG_KERNEL_MAX_UPROBE_NUM  32
+#define LTTNG_KERNEL_SESSION_NAME_LEN  256
 
 /*
  * LTTng DebugFS ABI structures.
@@ -178,4 +179,11 @@ struct lttng_kernel_filter_bytecode {
char data[0];
 } LTTNG_PACKED;
 
+/*
+ * kernel session name
+ */
+struct lttng_kernel_session_name {
+   char name[LTTNG_KERNEL_SESSION_NAME_LEN];
+} LTTNG_PACKED;
+
 #endif /* _LTTNG_KERNEL_H */
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools v2 1/4] Save registration time for app

[Jonathan Rajotte]

Reuse the registration time for path generation.

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/ust-app.c | 7 +++
 src/bin/lttng-sessiond/ust-app.h | 5 +
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/bin/lttng-sessiond/ust-app.c b/src/bin/lttng-sessiond/ust-app.c
index 4bee50496..443232e79 100644
--- a/src/bin/lttng-sessiond/ust-app.c
+++ b/src/bin/lttng-sessiond/ust-app.c
@@ -1831,15 +1831,12 @@ static void shadow_copy_channel(struct ust_app_channel 
*ua_chan,
 static void shadow_copy_session(struct ust_app_session *ua_sess,
struct ltt_ust_session *usess, struct ust_app *app)
 {
-   time_t rawtime;
struct tm *timeinfo;
char datetime[16];
int ret;
char tmp_shm_path[PATH_MAX];
 
-   /* Get date and time for unique app path */
-   time();
-   timeinfo = localtime();
+   timeinfo = localtime(>registration_time);
strftime(datetime, sizeof(datetime), "%Y%m%d-%H%M%S", timeinfo);
 
DBG2("Shadow copy of session handle %d", ua_sess->handle);
@@ -3376,6 +3373,8 @@ void ust_app_add(struct ust_app *app)
assert(app);
assert(app->notify_sock >= 0);
 
+   app->registration_time = time(NULL);
+
rcu_read_lock();
 
/*
diff --git a/src/bin/lttng-sessiond/ust-app.h b/src/bin/lttng-sessiond/ust-app.h
index b90ff4bce..d9279f0e4 100644
--- a/src/bin/lttng-sessiond/ust-app.h
+++ b/src/bin/lttng-sessiond/ust-app.h
@@ -298,6 +298,11 @@ struct ust_app {
 * to a negative value indicating that the agent application is gone.
 */
int agent_app_sock;
+   /*
+* Time at which the app is registred.
+* Used for path creation
+*/
+   time_t registration_time;
 };
 
 #ifdef HAVE_LIBLTTNG_UST_CTL
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools v2 2/4] Metadata: add env fields to ease lttng path hierarchy creation for viewer

[Jonathan Rajotte]

Add the following fields in the env section of the metadata:

  - trace_name
  The session name without datetime information.
  Hence when the session is an auto-generated one, only print
  LTTNG_DEFAULT_NAME.
  - trace_creation_datetime:
  The datetime at which the session was created.
  We use session->creation time for it.
  - tracer_buffering_scheme
  The buffering scheme used. The value can be uid or pid.
  - tracer_buffering_id
  The key used by the buffering scheme (uid/pid).
  - architecture_bit_width
  The bit width of the computer architecture (e.g 32 or 64)
  - vpid_datetime
  The registration time of the vpid for per-pid mode.

Adding these fields ensure that the trace itself carry information that
is normally carried via folder hierarchy. e.g

test-20190417-174951/  <- trace_name, 
trace_creation_datetime
└── ust<- domain
└── uid<- tracer_buffering_scheme
└── 1000   <- tracer_buffering_id
└── 64-bit <- architecture_bit_width
├── channel0_0
├── index
│   ├── channel0_0.idx
└── metadata

Per-pid buffering is quite similar.

auto-20190722-174816<- trace_name, 
trace_creation_datetime
└── ust <- domain
└── pid <- tracer_buffering_scheme
└── sample-ust-7640-20190722-174818 <- procname, tracer_buffering_id, 
vpid_datetime
├── my-channel_0
├── index
│   ├── my-channel_0.idx
    ├── metadata

Signed-off-by: Jonathan Rajotte 
---
 src/bin/lttng-sessiond/ust-app.c  |   5 +-
 src/bin/lttng-sessiond/ust-metadata.c | 171 ++
 src/bin/lttng-sessiond/ust-registry.c |   7 +-
 src/bin/lttng-sessiond/ust-registry.h |  18 ++-
 src/common/time.c |  32 +
 src/common/time.h |   9 ++
 6 files changed, 215 insertions(+), 27 deletions(-)

diff --git a/src/bin/lttng-sessiond/ust-app.c b/src/bin/lttng-sessiond/ust-app.c
index 443232e79..8b3028c57 100644
--- a/src/bin/lttng-sessiond/ust-app.c
+++ b/src/bin/lttng-sessiond/ust-app.c
@@ -1990,7 +1990,7 @@ static int setup_buffer_reg_pid(struct ust_app_session 
*ua_sess,
app->byte_order, app->version.major,
app->version.minor, reg_pid->root_shm_path,
reg_pid->shm_path,
-   ua_sess->euid, ua_sess->egid);
+   ua_sess->euid, ua_sess->egid, ua_sess->tracing_id, 
app->uid);
if (ret < 0) {
/*
 * reg_pid->registry->reg.ust is NULL upon error, so we need to
@@ -2057,7 +2057,8 @@ static int setup_buffer_reg_uid(struct ltt_ust_session 
*usess,
app->uint64_t_alignment, app->long_alignment,
app->byte_order, app->version.major,
app->version.minor, reg_uid->root_shm_path,
-   reg_uid->shm_path, usess->uid, usess->gid);
+   reg_uid->shm_path, usess->uid, usess->gid,
+   ua_sess->tracing_id, app->uid);
if (ret < 0) {
/*
 * reg_uid->registry->reg.ust is NULL upon error, so we need to
diff --git a/src/bin/lttng-sessiond/ust-metadata.c 
b/src/bin/lttng-sessiond/ust-metadata.c
index a657f7c5d..2641c0be1 100644
--- a/src/bin/lttng-sessiond/ust-metadata.c
+++ b/src/bin/lttng-sessiond/ust-metadata.c
@@ -217,6 +217,41 @@ void sanitize_ctf_identifier(char *out, const char *in)
}
 }
 
+static
+int print_escaped_ctf_string(struct ust_registry_session *session, const char 
*string)
+{
+   int ret;
+   size_t i;
+   char cur;
+
+   i = 0;
+   cur = string[i];
+   while (cur != '\0') {
+   switch (cur) {
+   case '\n':
+   ret = lttng_metadata_printf(session, "%s", "\\n");
+   break;
+   case '\\':
+   case '"':
+   ret = lttng_metadata_printf(session, "%c", '\\');
+   if (ret)
+   goto error;
+   /* We still print the current char */
+   /* Fallthrough */
+   default:
+   ret = lttng_metadata_printf(session, "%c", cur);
+   break;
+   }
+
+   if (ret)
+   goto error;
+
+   cur = string[++i];
+   }
+error:
+   return ret;
+}
+
 /* Called with session registry mutex held. */
 static
 int ust_metadata_e

[lttng-dev] [PATCH lttng-tools 2/3] Support LTTNG_KERNEL_SESSION_SET_NAME of lttng-modules

[Jonathan Rajotte]

Signed-off-by: Jonathan Rajotte 
---

This should also be backported to 2.11 allowing Babeltrace 2 to merge
traces from archived data (rotation) and output a trace with a similar
lttng tree hierarchy.

See [1] for the series to be applied to lttng-modules.

[1] https://lists.lttng.org/pipermail/lttng-dev/2019-August/029191.html

---
 src/bin/lttng-sessiond/kernel.c  | 14 ++
 src/common/kernel-ctl/kernel-ctl.c   | 10 ++
 src/common/kernel-ctl/kernel-ctl.h   |  1 +
 src/common/kernel-ctl/kernel-ioctl.h |  2 ++
 src/common/lttng-kernel.h|  8 
 5 files changed, 35 insertions(+)

diff --git a/src/bin/lttng-sessiond/kernel.c b/src/bin/lttng-sessiond/kernel.c
index b4fc995ce..7793ba6bc 100644
--- a/src/bin/lttng-sessiond/kernel.c
+++ b/src/bin/lttng-sessiond/kernel.c
@@ -125,6 +125,20 @@ int kernel_create_session(struct ltt_session *session, int 
tracer_fd)
 
DBG("Kernel session created (fd: %d)", lks->fd);
 
+   /*
+* This is necessary since the creation time is present in the session
+* name when it is generated.
+*/
+   if (session->has_auto_generated_name) {
+   ret = kernctl_session_set_name(lks->fd, DEFAULT_SESSION_NAME);
+   } else {
+   ret = kernctl_session_set_name(lks->fd, session->name);
+   }
+   if (ret) {
+   WARN("Could not set kernel session name for session %" PRIu64 " 
name: %s",
+   session->id, session->name);
+   }
+
return 0;
 
 error:
diff --git a/src/common/kernel-ctl/kernel-ctl.c 
b/src/common/kernel-ctl/kernel-ctl.c
index 047d40a34..6a37015ae 100644
--- a/src/common/kernel-ctl/kernel-ctl.c
+++ b/src/common/kernel-ctl/kernel-ctl.c
@@ -238,6 +238,16 @@ int kernctl_session_regenerate_statedump(int fd)
return LTTNG_IOCTL_CHECK(fd, LTTNG_KERNEL_SESSION_STATEDUMP);
 }
 
+int kernctl_session_set_name(int fd, const char *name)
+{
+   struct lttng_kernel_session_name session_name;
+
+   strncpy(session_name.name, name, LTTNG_KERNEL_SESSION_NAME_LEN);
+
+   return LTTNG_IOCTL_CHECK(fd, LTTNG_KERNEL_SESSION_SET_NAME,
+   _name);
+}
+
 int kernctl_create_stream(int fd)
 {
return compat_ioctl_no_arg(fd, LTTNG_KERNEL_OLD_STREAM,
diff --git a/src/common/kernel-ctl/kernel-ctl.h 
b/src/common/kernel-ctl/kernel-ctl.h
index 841c31da0..884929ac1 100644
--- a/src/common/kernel-ctl/kernel-ctl.h
+++ b/src/common/kernel-ctl/kernel-ctl.h
@@ -67,6 +67,7 @@ int kernctl_list_tracker_pids(int fd);
 
 int kernctl_session_regenerate_metadata(int fd);
 int kernctl_session_regenerate_statedump(int fd);
+int kernctl_session_set_name(int fd, const char *name);
 
 /* Buffer operations */
 
diff --git a/src/common/kernel-ctl/kernel-ioctl.h 
b/src/common/kernel-ctl/kernel-ioctl.h
index e7ff50b24..ce910e96f 100644
--- a/src/common/kernel-ctl/kernel-ioctl.h
+++ b/src/common/kernel-ctl/kernel-ioctl.h
@@ -145,6 +145,8 @@
 #define LTTNG_KERNEL_SESSION_METADATA_REGEN_IO(0xF6, 0x59)
 /* 0x5A and 0x5B are reserved for a future ABI-breaking cleanup. */
 #define LTTNG_KERNEL_SESSION_STATEDUMP _IO(0xF6, 0x5C)
+#define LTTNG_KERNEL_SESSION_SET_NAME  \
+   _IOR(0xF6, 0x5D, struct lttng_kernel_session_name)
 
 /* Channel FD ioctl */
 #define LTTNG_KERNEL_STREAM_IO(0xF6, 0x62)
diff --git a/src/common/lttng-kernel.h b/src/common/lttng-kernel.h
index cd1a15f67..001a16e2d 100644
--- a/src/common/lttng-kernel.h
+++ b/src/common/lttng-kernel.h
@@ -27,6 +27,7 @@
 
 #define LTTNG_KERNEL_SYM_NAME_LEN  256
 #define LTTNG_KERNEL_MAX_UPROBE_NUM  32
+#define LTTNG_KERNEL_SESSION_NAME_LEN  256
 
 /*
  * LTTng DebugFS ABI structures.
@@ -178,4 +179,11 @@ struct lttng_kernel_filter_bytecode {
char data[0];
 } LTTNG_PACKED;
 
+/*
+ * kernel session name
+ */
+struct lttng_kernel_session_name {
+   char name[LTTNG_KERNEL_SESSION_NAME_LEN];
+} LTTNG_PACKED;
+
 #endif /* _LTTNG_KERNEL_H */
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools 3/3] Support LTTNG_KERNEL_SESSION_SET_CREATION_DATETIME of lttng-modules

[Jonathan Rajotte]

Signed-off-by: Jonathan Rajotte 
---

This should also be backported to 2.11 allowing Babeltrace 2 to merge
traces from archived data (rotation) and output a trace with a similar
lttng tree hierarchy.

See [1] for the series to be applied to lttng-modules.

[1] https://lists.lttng.org/pipermail/lttng-dev/2019-August/029191.html
---
 src/bin/lttng-sessiond/kernel.c  |  6 ++
 src/common/kernel-ctl/kernel-ctl.c   | 15 +++
 src/common/kernel-ctl/kernel-ctl.h   |  1 +
 src/common/kernel-ctl/kernel-ioctl.h |  2 ++
 src/common/lttng-kernel.h|  8 
 5 files changed, 32 insertions(+)

diff --git a/src/bin/lttng-sessiond/kernel.c b/src/bin/lttng-sessiond/kernel.c
index 7793ba6bc..cedb9346c 100644
--- a/src/bin/lttng-sessiond/kernel.c
+++ b/src/bin/lttng-sessiond/kernel.c
@@ -139,6 +139,12 @@ int kernel_create_session(struct ltt_session *session, int 
tracer_fd)
session->id, session->name);
}
 
+   ret = kernctl_session_set_creation_time(lks->fd, 
session->creation_time);
+   if (ret) {
+   WARN("Could not set kernel session creation time for session %" 
PRIu64 " name: %s",
+   session->id, session->name);
+   }
+
return 0;
 
 error:
diff --git a/src/common/kernel-ctl/kernel-ctl.c 
b/src/common/kernel-ctl/kernel-ctl.c
index 6a37015ae..8c0025c93 100644
--- a/src/common/kernel-ctl/kernel-ctl.c
+++ b/src/common/kernel-ctl/kernel-ctl.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "kernel-ctl.h"
 #include "kernel-ioctl.h"
@@ -248,6 +249,20 @@ int kernctl_session_set_name(int fd, const char *name)
_name);
 }
 
+int kernctl_session_set_creation_time(int fd, time_t time)
+{
+   int ret;
+   struct lttng_kernel_session_creation_time creation_time;
+
+   ret = time_t_to_ISO8601(creation_time.iso8601, 
sizeof(creation_time.iso8601), time);
+   if (ret) {
+   return -1;
+   }
+
+   return LTTNG_IOCTL_CHECK(fd, LTTNG_KERNEL_SESSION_SET_CREATION_TIME,
+   _time);
+}
+
 int kernctl_create_stream(int fd)
 {
return compat_ioctl_no_arg(fd, LTTNG_KERNEL_OLD_STREAM,
diff --git a/src/common/kernel-ctl/kernel-ctl.h 
b/src/common/kernel-ctl/kernel-ctl.h
index 884929ac1..053e7df63 100644
--- a/src/common/kernel-ctl/kernel-ctl.h
+++ b/src/common/kernel-ctl/kernel-ctl.h
@@ -68,6 +68,7 @@ int kernctl_list_tracker_pids(int fd);
 int kernctl_session_regenerate_metadata(int fd);
 int kernctl_session_regenerate_statedump(int fd);
 int kernctl_session_set_name(int fd, const char *name);
+int kernctl_session_set_creation_time(int fd, time_t time);
 
 /* Buffer operations */
 
diff --git a/src/common/kernel-ctl/kernel-ioctl.h 
b/src/common/kernel-ctl/kernel-ioctl.h
index ce910e96f..8d39abbe3 100644
--- a/src/common/kernel-ctl/kernel-ioctl.h
+++ b/src/common/kernel-ctl/kernel-ioctl.h
@@ -147,6 +147,8 @@
 #define LTTNG_KERNEL_SESSION_STATEDUMP _IO(0xF6, 0x5C)
 #define LTTNG_KERNEL_SESSION_SET_NAME  \
_IOR(0xF6, 0x5D, struct lttng_kernel_session_name)
+#define LTTNG_KERNEL_SESSION_SET_CREATION_TIME \
+   _IOR(0xF6, 0x5E, struct lttng_kernel_session_creation_time)
 
 /* Channel FD ioctl */
 #define LTTNG_KERNEL_STREAM_IO(0xF6, 0x62)
diff --git a/src/common/lttng-kernel.h b/src/common/lttng-kernel.h
index 001a16e2d..2fd14dc1e 100644
--- a/src/common/lttng-kernel.h
+++ b/src/common/lttng-kernel.h
@@ -28,6 +28,7 @@
 #define LTTNG_KERNEL_SYM_NAME_LEN  256
 #define LTTNG_KERNEL_MAX_UPROBE_NUM  32
 #define LTTNG_KERNEL_SESSION_NAME_LEN  256
+#define LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN 26
 
 /*
  * LTTng DebugFS ABI structures.
@@ -186,4 +187,11 @@ struct lttng_kernel_session_name {
char name[LTTNG_KERNEL_SESSION_NAME_LEN];
 } LTTNG_PACKED;
 
+/*
+ * kernel session creation datetime
+ */
+struct lttng_kernel_session_creation_time {
+   char iso8601[LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN];
+} LTTNG_PACKED;
+
 #endif /* _LTTNG_KERNEL_H */
-- 
2.17.1

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

[lttng-dev] [PATCH lttng-tools 1/3] Metadata: add env fields to ease lttng path hierarchy creation for viewer

[Jonathan Rajotte]

Add the following fields in the env section of the metadata:

  - trace_name
  The session name without datetime information.
  Hence when the session is an auto-generated one, only print
  LTTNG_DEFAULT_NAME.
  - trace_creation_datetime:
  The datetime at which the session was created.
  We use session->creation time for it.
  - tracer_buffering_scheme
  The buffering scheme used. The value can be uid or pid.
  - tracer_buffering_id
  The key used by the buffering scheme (uid/pid).
  - architecture_bit_width
  The bit width of the computer architecture (e.g 32 or 64)
  - vpid_datetime
  The registration time of the vpid for per-pid mode.

Adding these fields ensure that the trace itself carry information that
is normally carried via folder hierarchy. e.g

test-20190417-174951/  <- trace_name, 
trace_creation_datetime
└── ust<- domain
└── uid<- tracer_buffering_scheme
└── 1000   <- tracer_buffering_id
└── 64-bit <- architecture_bit_width
├── channel0_0
├── index
│   ├── channel0_0.idx
└── metadata

Per-pid buffering is quite similar.

auto-20190722-174816<- trace_name, 
trace_creation_datetime
└── ust <- domain
└── pid <- tracer_buffering_scheme
└── sample-ust-7640-20190722-174818 <- procname, tracer_buffering_id, 
vpid_datetime
├── my-channel_0
├── index
│   ├── my-channel_0.idx
    ├── metadata

Signed-off-by: Jonathan Rajotte 
---

This should also be backported to 2.11 allowing Babeltrace 2 to merge
traces from archived data (rotation) and output a trace with a similar
lttng tree hierarchy.

---
 src/bin/lttng-sessiond/ust-app.c  |   5 +-
 src/bin/lttng-sessiond/ust-metadata.c | 171 ++
 src/bin/lttng-sessiond/ust-registry.c |   7 +-
 src/bin/lttng-sessiond/ust-registry.h |  18 ++-
 src/common/time.c |  32 +
 src/common/time.h |   9 ++
 6 files changed, 215 insertions(+), 27 deletions(-)

diff --git a/src/bin/lttng-sessiond/ust-app.c b/src/bin/lttng-sessiond/ust-app.c
index 443232e79..8b3028c57 100644
--- a/src/bin/lttng-sessiond/ust-app.c
+++ b/src/bin/lttng-sessiond/ust-app.c
@@ -1990,7 +1990,7 @@ static int setup_buffer_reg_pid(struct ust_app_session 
*ua_sess,
app->byte_order, app->version.major,
app->version.minor, reg_pid->root_shm_path,
reg_pid->shm_path,
-   ua_sess->euid, ua_sess->egid);
+   ua_sess->euid, ua_sess->egid, ua_sess->tracing_id, 
app->uid);
if (ret < 0) {
/*
 * reg_pid->registry->reg.ust is NULL upon error, so we need to
@@ -2057,7 +2057,8 @@ static int setup_buffer_reg_uid(struct ltt_ust_session 
*usess,
app->uint64_t_alignment, app->long_alignment,
app->byte_order, app->version.major,
app->version.minor, reg_uid->root_shm_path,
-   reg_uid->shm_path, usess->uid, usess->gid);
+   reg_uid->shm_path, usess->uid, usess->gid,
+   ua_sess->tracing_id, app->uid);
if (ret < 0) {
/*
 * reg_uid->registry->reg.ust is NULL upon error, so we need to
diff --git a/src/bin/lttng-sessiond/ust-metadata.c 
b/src/bin/lttng-sessiond/ust-metadata.c
index a657f7c5d..2641c0be1 100644
--- a/src/bin/lttng-sessiond/ust-metadata.c
+++ b/src/bin/lttng-sessiond/ust-metadata.c
@@ -217,6 +217,41 @@ void sanitize_ctf_identifier(char *out, const char *in)
}
 }
 
+static
+int print_escaped_ctf_string(struct ust_registry_session *session, const char 
*string)
+{
+   int ret;
+   size_t i;
+   char cur;
+
+   i = 0;
+   cur = string[i];
+   while (cur != '\0') {
+   switch (cur) {
+   case '\n':
+   ret = lttng_metadata_printf(session, "%s", "\\n");
+   break;
+   case '\\':
+   case '"':
+   ret = lttng_metadata_printf(session, "%c", '\\');
+   if (ret)
+   goto error;
+   /* We still print the current char */
+   /* Fallthrough */
+   default:
+   ret = lttng_metadata_printf(session, "%c", cur);
+   break;
+   }
+
+   if (ret)
+   goto error;

[lttng-dev] [PATCH lttng-modules 3/3] Introduce LTTNG_KERNEL_SESSION_SET_CREATION_TIME

[Jonathan Rajotte]

Add trace_creation_datetime to the metadata env field

This allows a viewer to get more information regarding the creation time
of a trace. This information is normally inferred from the trace
hierarchy.

The ABI expects an ISO8601 compliant string value. We leave the
formatting to the trace controller.

Signed-off-by: Jonathan Rajotte 
---

This should also be backported to 2.11 allowing Babeltrace 2 to merge
traces from archived data (rotation) and output a trace with similar
lttng tree hierarchy.

---
 lttng-abi.c| 27 +++
 lttng-abi.h|  7 +++
 lttng-events.c | 13 +
 lttng-events.h |  1 +
 4 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/lttng-abi.c b/lttng-abi.c
index aab2cac..cc8f183 100644
--- a/lttng-abi.c
+++ b/lttng-abi.c
@@ -470,6 +470,23 @@ int lttng_abi_session_set_name(struct lttng_session 
*session,
return 0;
 }
 
+static
+int lttng_abi_session_set_creation_time(struct lttng_session *session,
+   struct lttng_kernel_session_creation_time *time)
+{
+   size_t len;
+
+   len = strnlen(time->iso8601, 
LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN);
+
+   if (len == LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN) {
+   /* Time is too long/malformed */
+   return -EINVAL;
+   }
+
+   strcpy(session->creation_time, time->iso8601);
+   return 0;
+}
+
 /**
  * lttng_session_ioctl - lttng session fd ioctl
  *
@@ -589,6 +606,16 @@ long lttng_session_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
return -EFAULT;
return lttng_abi_session_set_name(session, );
}
+   case LTTNG_KERNEL_SESSION_SET_CREATION_TIME:
+   {
+   struct lttng_kernel_session_creation_time time;
+
+   if (copy_from_user(,
+   (struct lttng_kernel_session_creation_time 
__user *) arg,
+   sizeof(struct 
lttng_kernel_session_creation_time)))
+   return -EFAULT;
+   return lttng_abi_session_set_creation_time(session, );
+   }
default:
return -ENOIOCTLCMD;
}
diff --git a/lttng-abi.h b/lttng-abi.h
index 0dd9a9f..c292de0 100644
--- a/lttng-abi.h
+++ b/lttng-abi.h
@@ -21,6 +21,7 @@
 
 #define LTTNG_KERNEL_SYM_NAME_LEN  256
 #define LTTNG_KERNEL_SESSION_NAME_LEN  256
+#define LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN 26
 
 enum lttng_kernel_instrumentation {
LTTNG_KERNEL_TRACEPOINT = 0,
@@ -124,6 +125,10 @@ struct lttng_kernel_session_name {
char name[LTTNG_KERNEL_SESSION_NAME_LEN];
 } __attribute__((packed));
 
+struct lttng_kernel_session_creation_time {
+   char iso8601[LTTNG_KERNEL_SESSION_CREATION_TIME_ISO8601_LEN];
+} __attribute__((packed));
+
 enum lttng_kernel_calibrate_type {
LTTNG_KERNEL_CALIBRATE_KRETPROBE,
 };
@@ -219,6 +224,8 @@ struct lttng_kernel_filter_bytecode {
 #define LTTNG_KERNEL_SESSION_STATEDUMP _IO(0xF6, 0x5C)
 #define LTTNG_KERNEL_SESSION_SET_NAME  \
_IOR(0xF6, 0x5D, struct lttng_kernel_session_name)
+#define LTTNG_KERNEL_SESSION_SET_CREATION_TIME \
+   _IOR(0xF6, 0x5E, struct lttng_kernel_session_creation_time)
 
 /* Channel FD ioctl */
 #define LTTNG_KERNEL_STREAM_IO(0xF6, 0x62)
diff --git a/lttng-events.c b/lttng-events.c
index 2e7670b..38cd444 100644
--- a/lttng-events.c
+++ b/lttng-events.c
@@ -2514,15 +2514,16 @@ error:
 }
 
 static
-int print_metadata_session_name(struct lttng_session *session)
+int print_metadata_escaped_field(struct lttng_session *session, const char 
*field,
+   const char *field_value)
 {
int ret;
 
-   ret = lttng_metadata_printf(session, "  trace_name = \"");
+   ret = lttng_metadata_printf(session, "  %s = \"", field);
if (ret)
goto error;
 
-   ret = print_escaped_ctf_string(session, session->name);
+   ret = print_escaped_ctf_string(session, field_value);
if (ret)
goto error;
 
@@ -2619,7 +2620,11 @@ int _lttng_session_metadata_statedump(struct 
lttng_session *session)
if (ret)
goto end;
 
-   ret = print_metadata_session_name(session);
+   ret = print_metadata_escaped_field(session, "trace_name", 
session->name);
+   if (ret)
+   goto end;
+   ret = print_metadata_escaped_field(session, "trace_creation_datetime",
+   session->creation_time);
if (ret)
goto end;
 
diff --git a/lttng-events.h b/lttng-events.h
index bdd73ff..8fe36a7 100644
--- a/lttng-events.h
+++ b/lttng-events.h
@@ -522,6 +522,7 @@ struct lttng_session {
/* Hash table of events */
struct lttng_event_ht events_ht;
char name[LTTNG_KERNEL_SESSION_NAME_LEN];
+   char creation_time[LTTNG_KERNEL_SESSION_CREATIO