Re: [lttng-dev] lttng load misbehaving

[Thibault, Daniel]

-Message d'origine-
Envoyé : 15 décembre 2016 11:56

> You might not have saved the edited file.

   I triple-checked that.  It is not the case.

   I had an inspiration and was able to confirm it: 
https://bugs.lttng.org/issues/1083

Daniel U. Thibault, M.Sc.²
Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada
Gouvernement du Canada
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] lttng load misbehaving

[Thibault, Daniel]

   I've just had the weirdest thing happen.  I'm running three copies of the 
same VM (Ubuntu 14.04.4 with LTTng 2.8.0) and the same LTTng trace capture 
script, the only variation being adjustments to the trace storage path to 
accommodate slightly different shared folder arrangements between the VM and 
its host.

   On one machine, after I edited ~/.lttng/.lttng to change its 
sessions: session: output: consumer_output: destination: path member, having 
lttng load the session resulted in the previous path being used (I can see this 
by doing 'lttng load ' and then 'lttng list ').  
Bizarre!  This did not happen on the other machines, so I'm really unsure if 
its reproducible.  Is there some kind of caching possibly going on?  How would 
I go about investigating this?  (I've taken a snapshot of the VM just in case)

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] The LTTng documentation

[Thibault, Daniel]

On http://lttng.org/docs/v2.8/, within the Acknowledgements, would it be 
possible to add a link to the quoted "LTTng Comprehensive User’s Guide"?  Both 
guides are now published and can be downloaded from:

http://pubs.drdc-rddc.gc.ca/SEARCH/BASIS/pcandid/www/engpub/SDW?M%3D1%26W%3DTITLE++INC+%27LTTNG%27

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier 
Recherche et développement pour la défense Canada / Gouvernement du Canada 
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538 
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre Defence Research and 
Development Canada / Government of Canada daniel.thiba...@drdc-rddc.gc.ca / 
Tel: 418-844-4000x4245 Fax: 418-844-4538 daniel.thiba...@forces.gc.ca / Tel: 
418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] Python 3.5 bindings broken for babeltrace 1.4-stable ?

[Thibault, Daniel]

   I'm having a problem with the babeltrace (1.4.0-stable) Python 3.5 bindings.

   This is similar to Jean Spector's earlier (Sat, 29 Oct 2016 16:55:15 +0300) 
problem ("[lttng-dev] Babeltrace python bindings documentation is not 
up-to-date") although substantially different.

   I earlier had babeltrace used successfully from Python 3 (after a small 
binding tweak (bug 1051), albeit with some weird crashes (bugs 1052 and 1054)), 
and I'm now trying to run the same script with a refreshed babeltrace build, 
without success.

CentOS Linux release 7.1.1503 (Core) 3.10.0-229.4.2.el7.x86_64
babeltrace-stable-1.4-09c9a6e
(LTTng tools is NOT installed)
rh-python35-python-devel (rh-python35-python, -libs, -pip, -setuptools, 
rh-python35-runtime) installed
$ python --version
Python 2.7.5
$ python3 --version
Python 3.5.1 :: Anaconda 4.0.0 (64-bit)

   If I run the sample code on 
http://lttng.org/docs/v2.8/#doc-viewing-and-analyzing-your-traces-bt-python ($ 
python3 /path/to/top5proc.py /path/to/trace/kernel) I get:

Traceback (most recent call last):
  File "/.../top5proc.py", line 70, in 
sys.exit(0 if top5proc() else 1)
  File "/.../top5proc.py", line 13, in top5proc
col = babeltrace.TraceCollection()
AttributeError: module 'babeltrace' has no attribute 'TraceCollection'

The babeltrace-stable-1.4-09c9a6e package was built and installed successfully 
(logs available), though I had to add a symbolic link to PyCharm Community 
Edition 2016.1.3 in ~/anaconda3/lib/python3.5/site-packages called babeltrace 
and pointing to /usr/local/lib/python3.5/site-packages/babeltrace to get 
PyCharm to recognize the package.  This is a secondary issue (bug 1076) that 
has no bearing since the test described above was entirely conducted from the 
command line.  Still, PyCharm reports the same error (although with a different 
stack) when running similar code.

The bottom line is that Python 3.5 is not recognizing TraceCollection() as a 
class constructor.

Since babeltrace 2.0 will keep the same Python bindings (Sat, 29 Oct 2016 
17:49:26 -0400, Philippe Proulx: "the Python bindings (this API will remain 
maintained)"), waiting for its release is not pertinent.

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [lttng-ust] [babeltrace] use case question -field names in event classes

[Thibault, Daniel]

--
On Tue, Oct 11, 2016 at 4:46 PM, Staffan Tjernstrom 
 wrote:
> We have a situation where we have a significant number (1000's) of 
> log-style trace messages generated by a large group of (sometime
> offsite) developers.
>
> Unfortunately the tracepoint definitions are maintained by a small 
> group of central developers.
>
> So we have a need for generic tracepoint definitions, without losing 
> the ability to tailor the output from individual log messages.
>
> One approach we've come up with involves including the labels as part 
> of the parameter pack:
>
> TRACEPOINT_EVENT(
> my_app,
> two_ints_and_string,
> TP_ARGS(
> // some pre-amble fields removed for clarity
> char const *, label1_arg,
> int, value1_arg,
> char const *, label2_arg,
> int, value2_arg,
> char const *, label3_arg,
> char const *, value3_arg
> ),
> TP_FIELDS(
> // pre-amble removed for clarity
> ctf_string( label1, label1_arg )
> ctf_integer(int, value1, value1_arg)
> ctf_string( label2, label2_arg )
> ctf_integer(int, value2, value2_arg)
> )
> )
>
> and we can then call this from multiple locations in our general 
> code-base using:
>
> tracepoint(my_app, two_ints_and_string, "widget_height", 19, 
> "widget_width", 23, "widget_name", widget_name_as_cstring);
>
> tracepoint(my_app, two_ints_and_string, "x_coordinate", x, 
> "y_coordinate", y, "point_type", "star");
>
> The issue with this is that the output obviously treats the field 
> names and their values as individual items, so we get output like
>
> label1 = "widget_height", value1 = 19, label2 = "widget_width", value2
> =- 23, label3 = "widget_name", value3 = "topper"
> label1 = "x_coordinate", value1 = -23, label2 = "y_coordinate", value2 
> = 25532, label3 = "point_type", value3 = "star"
>
> But of course we need to mechanically scrape / inspect the output, so 
> what we'd really like would be output something more like:
>
> widget_height = 19, widget_width = 23, widget_name = "topper"
> x_coordinate = -23, y_coordinate = 25532, point_type = "star"
>
> Post-processing of the babeltrace output is of course one option 
> (using -n none), but it feels like the wrong choice (adding more steps 
> to the tracing chain).
>
> Does anyone out there have any better ideas how to achieve having our 
> cake ( a small number of generic tracepoints ), and eating it ( 
> user-defined field names )?

Have you thought about using TRACEPOINT_EVENT_CLASS and 
TRACEPOINT_EVENT_INSTANCE?

Untested:

TRACEPOINT_EVENT_CLASS(
 my_app,
 two_ints_and_string,
 TP_ARGS(
 // some pre-amble fields removed for clarity
 int, value1_arg,
 int, value2_arg,
 char const *, value3_arg
 ),

TRACEPOINT_EVENT_INSTANCE(
 my_app,
 two_ints_and_string,
 two_ints_and_string_widget,
 TP_ARGS(
 // repeats the TRACEPOINT_EVENT_CLASS TP_ARGS
 ),

TRACEPOINT_EVENT_INSTANCE(
 my_app,
 two_ints_and_string,
 two_ints_and_string_point,
 TP_ARGS(
 // repeats the TRACEPOINT_EVENT_CLASS TP_ARGS
 ),

tracepoint(my_app, two_ints_and_string_widget, 19, 23, widget_name_as_cstring);
tracepoint(my_app, two_ints_and_string_point, x, y, "star");

You would only need one TRACEPOINT_EVENT_CLASS per signature, and could tailor 
the event names to make the arguments as obvious as they need to be.

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] lttng-sessiond as a CentOS 7 service

[Thibault, Daniel]

Using:
lttng-modules-stable-2.8-2.8.2-e840206
userspace-rcu-stable-0.9-6051170
lttng-ust-stable-2.8-cf18865
lttng-tools-stable-2.8-2.8.2-48262f1
on:
Red Hat Enterprise Linux Server release 7.2 (Maipo) (RHEL 7.2 64-bits)
Kernel 3.10.0-327.el7.x86_64

I'm having trouble with my installation of lttng-sessiond as a service.  If I 
run lttng-sessiond using either -b, -d, or just -vvv, it works fine (I can 
interrogate 'lttng list -u' from a tracing user shell and detect the process 
using 'ps -e | grep sessiond').

But when I launch the service, I end up with a "successfully dead" daemon:

# systemctl start lttng-sessiond
# systemctl status lttng-sessiond
* lttng-sessiond.service - LTTng central tracing registry session daemon
   Loaded: loaded (/etc/systemd/system/lttng-sessiond.service; enabled; vendor 
preset: enabled)
   Active: inactive (dead) since ...
  Process: 5865 ExecStart=/usr/local/bin/lttng-sessiond -d (code=exited, 
status=0/SUCCESS)
 Main PID: 5865 (code=exited, status=0/SUCCESS)

There's nothing in dmesg.

The service is set up like so:

$ sudo ln -s /etc/systemd/system/lttng-sessiond.service 
/etc/systemd/system/multi-user.target.wants/lttng-sessiond.service
$ cat > ~/lttng-sessiond.service << END
[Unit]
Description=LTTng central tracing registry session daemon

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/lttng-sessiond -d
Restart=on-abort

[Install]
WantedBy=multi-user.target
END
$ sudo mv ~/lttng-sessiond.service /etc/systemd/system/lttng-sessiond.service

What am I doing wrong?

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] LTTng and multiple kernels

[Thibault, Daniel]

   Assume we have this system with a choice of kernels at boot time (for 
instance, between 2.6.18, 2.6.18-128.el5, and 2.6.18-grsec).  Do we need to do 
multiple LTTng builds?  For some packages only, maybe (e.g., lttng-modules)?  
If so, can they cohabit without trouble, or will we need to run some sort of 
LTTng-fixing script every time we switch kernels?

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] LTTng 2.9 sessiond misbehaving

[Thibault, Daniel]

Interesting.  Rebuilt the entire LTTng set with the stable-1.8 releases 
(stable-0.9 for userspace-rcu) and I see the same behaviour:
When I hit ctrl-c in the daemon's shell, it doesn't respond and the CPU usage 
goes crazy (~90%).  Can't sudo kill it (or lttng-runas) either.

What's strange is that if instead of:

$ lttng-sessiond -vvv 2>&1 | tee lttng-sessiond.2.log

I do:

$ lttng-sessiond 2>&1 | tee lttng-sessiond.3.log

Then ctrl-c terminates lttng-sessiond normally.

Using just the first level of verbosity:

$ lttng-sessiond -v 2>&1 | tee lttng-sessiond.4.log

also misbehaves.  Somehow -v is responsible?

At this point, should I open a bug?

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] LTTng 2.9 sessiond misbehaving

[Thibault, Daniel]

System profile:

Ubuntu 12.04.5 LTS precise, kernel 3.9.3
lttng-modules-2.9.0-pre-17-152fe7f
userspace-rcu-0.10-pre-2-d8a4979
lttng-ust-2.9.0-pre-84-4c62d8d
lttng-tools-2.9.0-pre-258-36bc42d

Running a user-local lttng-sessiond from the command line (after shutting down 
the root service):

$ lttng-sessiond -vvv 2>&1 | tee lttng-sessiond.1b.log

So far so good.  I test the daemon with 'lttng list' from another shell.  But 
when I hit ctrl-c in the daemon's shell, it doesn't respond and the CPU usage 
goes crazy (~90%).  Can't sudo kill it either.

dmesg is utterly silent.

What is happening?

The log is available; here are the last few lines:

$ lttng-sessiond -vvv 2>&1 | tee lttng-sessiond.2.log
...
DEBUG3 - 09:53:51.873996 [3186/3189]: [ht-thread] Polling. (in 
thread_ht_cleanup() at ht-cleanup.c:124)
DEBUG3 - 09:53:51.874189 [3186/3186]: Session daemon client socket 14 and 
application socket 15 created (in init_daemon_socket() at main.c:5182)
DEBUG3 - 09:53:51.874203 [3186/3186]: Created hashtable size 4 at 0x1635110 of 
type 2 (in lttng_ht_new() at hashtable.c:145)
DEBUG3 - 09:53:51.874205 [3186/3186]: Global buffer per UID registry 
initialized (in buffer_reg_init_uid_registry() at buffer-registry.c:99)
...
DEBUG1 - 09:54:10.381606 [3186/3191]: Wait for client response (in 
thread_manage_clients() at main.c:4455)
DEBUG1 - 09:54:10.382236 [3186/3191]: Receiving data from client ... (in 
thread_manage_clients() at main.c:4500)
DEBUG1 - 09:54:10.383618 [3186/3191]: Processing client command 13 (in 
process_client_msg() at main.c:2984)
DEBUG1 - 09:54:10.383812 [3186/3191]: Counting number of available session for 
UID 1000 GID 1000 (in lttng_sessions_count() at main.c:2953)
DEBUG1 - 09:54:10.383923 [3186/3191]: Getting all available session for UID 
1000 GID 1000 (in cmd_list_lttng_sessions() at cmd.c:3098)
DEBUG1 - 09:54:10.384067 [3186/3191]: Sending response (size: 20, retcode: 
Success (10)) (in thread_manage_clients() at main.c:4550)
DEBUG1 - 09:54:10.384221 [3186/3191]: Clean command context structure (in 
clean_command_ctx() at main.c:791)
DEBUG1 - 09:54:10.384330 [3186/3191]: Accepting client command ... (in 
thread_manage_clients() at main.c:4403)
^C

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Babeltrace, Python3, and the Event Declarations

[Thibault, Daniel]

-Message d'origine-
Date: Wed, 20 Jul 2016 13:19:55 -0400
From: Philippe Proulx 

>>I'm tinkering with the Python 3 bindings for babeltrace, and I've come 
>> upon an odd feature: for a given trace, if I ask for the EventDeclarations 
>> (using the TraceHandle), I end up getting the set of event declarations 
>> duplicated as many times as there are channels. And I mean exact duplicates.
>>
>>It's understandable that event declarations may recur between traces part 
>> of a single collection, but within a single trace?  And between channels?

But is it a bug?  Looking at my saved session definition (session_name.lttng 
file), I see the event declarations are subordinate to the channels, just like 
context.  It seems a bug that an event declaration that I've assigned to one 
channel —and one channel only— should be reported by every single channel.

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] Babeltrace, Python3, and the Event Declarations

[Thibault, Daniel]

   I'm tinkering with the Python 3 bindings for babeltrace, and I've come upon 
an odd feature: for a given trace, if I ask for the EventDeclarations (using 
the TraceHandle), I end up getting the set of event declarations duplicated as 
many times as there are channels. And I mean exact duplicates.

   It's understandable that event declarations may recur between traces part of 
a single collection, but within a single trace?  And between channels?

   I looked at the raw metadata file of the trace, and that duplication is also 
present, so I suppose other babeltrace bindings than Python will run into this.

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Is LTTng self-conscious?

[Thibault, Daniel]

> De : Mathieu Desnoyers [mailto:mathieu.desnoy...@efficios.com] 
> Envoyé : 13 juillet 2016 13:44
>
> However, if we were to implement a "blocking" mode as an alternative to the
> "discard" and "overwrite" modes of lttng when dealing with buffer full 
> conditions,
> we would need to be very cautious not to deadlock the system in such 
> situation.
> With both "discard" and "overwrite" buffering strategies, we cannot cause 
> system
> hang even in such extreme situations.
>
> Mathieu

   Couldn't lttng-untrack be used to fix this?  I was thinking of automatically 
untracking all instances of lttng-sessiond, lttng-consumerd, and lttng-runas.

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] Is LTTng self-conscious?

[Thibault, Daniel]

   Specifically, if LTTng is tracing all system calls on a machine and saving 
the trace locally, does it capture its own system calls (like disc access)? If 
it does, wouldn't this lead to unending echoes? Example: a disc access occurs, 
and the system call event is captured to the circular event buffer. After a 
short while, the consumer daemon writes the buffer contents to disc, which 
causes a system call event to be captured to the circular event buffer, and so 
on ad infinitam?

   If LTTng is self-conscious and avoids tracing itself, exactly what does it 
omit?

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale

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

[lttng-dev] Tracking children

[Thibault, Daniel]

   The new 'tracking' facility of LTTng 2.7 is very interesting.  Comparison 
with strace is unavoidable.

   Has any thought been given to providing a track option that would mimic 
strace's -f option?  Specifically, strace -f will trace not only (all threads 
of) the target process but also all of its child processes (those that are 
forked/vforked/cloned off) (Note that all of these *functions* go through a 
single *system call*: clone; presumably Plan 9's rfork does the same).  Given a 
similar option, say 'track --children', LTTng would automatically add to the 
session's tracking white list any processes cloned off of tracked processes 
(execve is not a concern since it preserves the PID).

   Right now, this isn't easily done: one would need to attach a listener to a 
live trace of the (tracked) clone system calls which would add the cloned off 
process to the white list.  Because this would be done at the consumer level, 
there is a risk of losing the first few system calls generated by the children 
(the delay corresponds to the clone system call events transiting through the 
LTTng event capture buffer and out through the consumer daemon to the listener, 
plus the listener's reaction time).

   In a slightly different train of thought, an strace-like wrapper (previously 
mentioned in GSoC 2013, I think) would be nice: a way to launch a process from 
a command line or shell script such that it is tracked by LTTng from its very 
inception.  Something like 'lttng-strace (-k | -u) [-s ] [--children] 
-- '.  Come to think of it, this could be done by the LTTng track 
command if it detected the -- option and treated the remainder of its command 
line as the process-launching command line (this would be antithetical to the 
--pid and --all options, of course).

   Shall I create a feature request?

   I also take it, reading 
http://lttng.org/docs/#doc-enabling-disabling-channels, that system call events 
can now be assigned to multiple channels within a session?

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] lttng-modules-27.0-stable and CentOS 7.0

[Thibault, Daniel]

--
Date: Tue, 20 Oct 2015 14:28:31 +
From: "Thibault, Daniel" <daniel.thiba...@drdc-rddc.gc.ca>
--
> lttng-modules-2.7.0-stable won't compile under CentOS 7.0. Details here: 
> http://bugzilla.redhat.com/show_bug.cgi?id=1273484
>
> Not sure if the problem is with gcc or LTTng

   Well, that turned out to be because the virtual machine was running out of 
memory during the compilation of the system call probes.  I increased it from 1 
GiB to 2 GiB and recompiled with no problem.

   I do get the repeated 'Can't read private key' warnings when installing the 
modules, even though lsmod says they load correctly.

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier 
Recherche et d?veloppement pour la d?fense Canada / Gouvernement du Canada 
daniel.thiba...@drdc-rddc.gc.ca / T?l: 418-844-4000x4245 T?l?c: 418-844-4538 
daniel.thiba...@forces.gc.ca / T?l: 418-844-4000x4245 T?l?c: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre Defence Research and 
Development Canada?/ Government of Canada daniel.thiba...@drdc-rddc.gc.ca / 
Tel: 418-844-4000x4245 Fax: 418-844-4538 daniel.thiba...@forces.gc.ca / Tel: 
418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du minist?re de la D?fense nationale

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

[lttng-dev] lttng-modules-27.0-stable and CentOS 7.0

[Thibault, Daniel]

lttng-modules-2.7.0-stable won't compile under CentOS 7.0. Details here: 
http://bugzilla.redhat.com/show_bug.cgi?id=1273484

Not sure if the problem is with gcc or LTTng

Daniel U. Thibault, M.Sc.²

Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Computer Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale

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

[lttng-dev] CentOS 7 and liburcu-common.so.3

[Thibault, Daniel]

I've grabbed recent source tarballs of the LTTng suite:

lttng-modules a606b6e 2.6.2-2 (2.6.0-rc1-101) 25 jun 2015 13:30:55
userspace-rcu b0a841b 0.8.7-13 (0.8.0-96) 8 Jul 2015 18:43:01
lttng-ust d8ecdf4 2.6.2.-20 (2.6.0-rc1-82)  8 Jul 2015 18:31:27
lttng-tools 7daee93 2.6.0-88 (2.6.0-rc1-241) 13 Jul 2015 15:21:01

and built them on two systems.  The first is a Ubuntu 15.04 vivid 
3.19.0-16-generic x86_64, the second is a CentOS Linux release 7.1.1503 (Core) 
3.10.0-229.el7 x86_64.
The first is also host to the second, which is a virtual machine.

Everything built and installed fine on both systems.  However, something 
happens on the CentOS that does not on the Ubuntu (both are virgin, with no 
tracing group yet, nor any automatic lttng-sessiond daemon):

$ su
# lttng create test_session
Spawning a session daemon
Warning: No tracing group detected
Session test_session created.
Traces will be written in /root/lttng-traces/ test_session-20150715-165116
# lttng enable-event -k -a

At this point, Ubuntu goes on with:

Warning: No tracing group detected
All Kernel events are enabled in channel channel0

While CentOS 7 does:

lttng-consumerd: error while loading shared libraries: liburcu-common.so.3: 
cannot open shared object file: No such file or directory
Error: Condition timed out.  The consumer thread was never ready. Killing it
Error: Fatal error spawning consumer control thread
Error: Events: Kernel consumer start failed (channel channel0, session 
test_session)
Error: Command error

At this point the system monitor shows lttng-sessiond and lttng-consumerd still 
up (so I guess the killing failed too).  If I then kill lttng-sessiond:

# kill 3425
# PERROR - 17:22:17.123456 [3425/3425]: kernel consumer err_sock close: Bad 
file descriptor (in close_consumer_sockets() at main.c:529)

What's strange is that liburcu-common.so.3 is present in the CentOS system, in 
the same place, and is found in the same way by 'whereis'.  Any clues?

Daniel U. Thibault, M.Sc.²

Scientifique de la défense, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thiba...@drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thiba...@forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538

Defence Scientist, MCCS-SPC, Valcartier Research Centre 
Defence Research and Development Canada / Government of Canada
daniel.thiba...@drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thiba...@forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538

DRDC is an agency of the Department of National Defence / RDDC est une agence 
du ministère de la Défense nationale

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

Re: [lttng-dev] Can't get any event output from the demo exe

[Thibault, Daniel]

--
Date: Tue, 17 Mar 2015 08:49:59 +0100
From: Wolfgang Rostek wolfgang.ros...@gmx.de

 row@cobra7:~$ lsb_release -sd
 Ubuntu 14.04.1 LTS

 row@cobra7:~$ file /sbin/init
 /sbin/init: ELF 32-bit LSB  shared object, Intel 80386, version 1 (SYSV), 
 dynamically linked (uses shared libs), for GNU/Linux 2.6.24, 
 BuildID[sha1]=c394677bccc720a3bb4f4c42a48e008ff33e39b1, stripped = 32bit

Is your host system 32- or 64-bit?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
 LinkedIn: http://ca.linkedin.com/in/daniel-u-thibault/
 Research Gate: https://www.researchgate.net/profile/Daniel_Thibault/

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

[lttng-dev] Fun with glibc

[Thibault, Daniel]

   Let's assume I'm trying to instrument glibc.  Making glibc is tricky by 
itself, but the following works under Ubuntu 14.04 and glibc 2.15 (obtained 
from ftp.gnu.org/gnu/glibc/). I have deployed glibc-2.15.tar.gz to a local 
./glibc-2.15 folder and created a sibling ./glibc-build folder:

glibc-build$ ../glibc-2.15/configure CFLAGS=-O2 -U_FORTIFY_SOURCE 
-fno-stack-protector --prefix=/home/user/path/usr-local 
--with-pkgversion=user-glibc  configure.log
glibc-build$ make  make.log

   Now I take a simple glibc service, such as printf 
(glibc-2.15/stdio-common/printf.c), and try to instrument it.  I modify 
printf.c like this:

#include libioP.h
#include stdarg.h
#include stdio.h

//THREE NEW LINES
#define TRACEPOINT_DEFINE
#define TRACEPOINT_PROBE_DYNAMIC_LINKAGE
#include printf-tp.h

#undef printf

/* Write formatted output to stdout from the format string FORMAT.  */
/* VARARGS1 */
int
__printf (const char *format, ...)
{
  va_list arg;
  int done;

//ONE NEW LINE
  tracepoint(libc_tracer, printf);
  va_start (arg, format);
  done = vfprintf (stdout, format, arg);
  va_end (arg);

  return done;
}

   The tracepoint is a simple one.

glibc-2.15/stdio-common/printf-tp.c :

#define TRACEPOINT_CREATE_PROBES
#include printf-tp.h

glibc-2.15/stdio-common/printf-tp.h :

usual preface
TRACEPOINT_EVENT(
libc_tracer,
printf,
TP_ARGS(),
TP_FIELDS()
)
TRACEPOINT_LOGLEVEL(
libc_tracer,
printf,
TRACE_INFO)
usual postface

   This is then compiled manually in place:

glibc-2.15/stdio-common$ gcc -I. -fPIC -c -o libprintf-tp.o printf-tp.c
glibc-2.15/stdio-common$ gcc -shared -Wl,-soname,libprintf-tp.so.1 
-Wl,-no-as-needed -o libprintf-tp.so.1.0 -L/usr/local/lib -llttng-ust 
libprintf-tp.o
glibc-2.15/stdio-common$ ln -sf libprintf-tp.so.1.0 libprintf-tp.so.1
glibc-2.15/stdio-common$ ln -sf libprintf-tp.so.1 libprintf-tp.so

   Pretty standard so far (using LTTng 2.3.0).

   The goal is to run apps from the instrumented glibc (libc.so.6) by 
LD_PRELOADing it (or installing it as the standard glibc) that become 
LTTng-active (provide user-space events) if the tracepoint provider shared 
object is also preloaded.  This is similar to the standard dynamically-loaded 
statically-unaware approach to app instrumentation, where the instrumented app 
runs fine without the tracepoint provider shared object, and becomes 
LTTng-active only if the latter is preloaded.

   The glibc make doesn't like this, however.  It fails with a bunch of 
undefined references to dlsym, dlopen, dlclose (in __tracepoint__init_urcu_sym, 
__tracepoints__init, __tracepoints__ptrs_init, __tracepoints__destroy, 
__tracepoints__ptrs_destroy) when it tries to use libc_pic.os in the final(?) 
construction of libc.so.  (I can provide the make log, of course)

   Anybody else tried to do something like this?  What is the least intrusive 
way of getting an LTTng-instrumented libc.so to compile?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
 LinkedIn: http://ca.linkedin.com/in/daniel-u-thibault/
 Research Gate: https://www.researchgate.net/profile/Daniel_Thibault/

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

Re: [lttng-dev] Errors compiling converted tp file

[Thibault, Daniel]

 Let me start by thanking you for all the support you give (it is impressingly 
 fast).
 
 So if I look in the repo, with the ppa installed, I can't find liburcu:

 $ cat /etc/apt/sources.list.d/lttng-ppa-precise.list
 deb http://ppa.launchpad.net/lttng/ppa/ubuntu precise main deb-src 
 http://ppa.launchpad.net/lttng/ppa/ubuntu precise main

 (I have asked my admin to do an apt-get update)

 $ apt-cache search lttng
 lttng-modules-dkms - Linux Trace Toolkit (LTTng) kernel modules (DKMS) 
 lttng-tools - LTTng control and utility programs
 liblttng-ust0 - LTTng 2.0 Userspace Tracer (libraries) liblttng-ust-dev - 
 LTTng 2.0 Userspace Tracer (development files) liblttng-ctl-dev - LTTng 
 control and utility library (development files)
 liblttng-ctl0 - LTTng control and utility library liblttng-ust-java-jni - 
 LTTng 2.0 Userspace Tracer (JNI interface) liblttng-ust-java - LTTng 2.0 
 Userspace Tracer (Java support library) python-lttng - Python bindings for 
 LTTng
 liblttng-ust-ctl2 - LTTng 2.0 Userspace Tracer (trace control library)

 $ apt-cache search liburcu
 liburcu-dev - a userspace RCU (read-copy-update) library - development files
 liburcu1 - a userspace RCU (read-copy-update) library
 liburcu2 - a userspace RCU (read-copy-update) library

 So it looks like my aptitude is not aware of a package called liburcu without 
 a postfix. Even if I'd purge and reinstall (which seems like a very good 
 idea) I don't see if I can access the right library this way.

 Yan Grange

If you visit https://launchpad.net/~lttng/+archive/ppa you'll see

babeltrace  1.2.y+stable+bzr710+pack25+201412120847~ubuntu15.04.1
liburcu 0.8.x+stable+bzr1060+pack22+201411140046~ubuntu15.04.1
lttng-modules   2.5.x+stable+bzr634+pack21+201412111931~ubuntu15.04.1
lttng-tools 2.5.x+stable+bzr2423+pack12+201412110246~ubuntu15.04.1
lttng-ust   2.5.x+stable+bzr1802+pack45+201412111801~ubuntu15.04.1

   The packages you see in http://ppa.launchpad.net/lttng/ppa/ubuntu depend on 
your hardware.  We have:

amd64:
liburcu-dev
lttng-modules-dkms
lttng-tools
babeltrace
libbabeltrace0
liburcu1
libbabeltrace-dev
liblttng-ust0
liblttng-ust-dev
liblttng-ctl-dev
liblttng-ctl0
libbabeltrace-ctf-dev
libbabeltrace-ctf0
liblttng-ust-java-jni
liblttng-ust-java
liburcu2
python-lttng
liblttng-ust-ctl2
libbabeltrace1
libbabeltrace-ctf1
python3-babeltrace

armel:
lttng-modules-dkms
liblttng-ust-java

armhf:
lttng-modules-dkms
liblttng-ust-java

i386:
liburcu-dev
lttng-modules-dkms
lttng-tools
babeltrace
libbabeltrace0
liburcu1
libbabeltrace-dev
liblttng-ust0
liblttng-ust-dev
liblttng-ctl-dev
liblttng-ctl0
libbabeltrace-ctf-dev
libbabeltrace-ctf0
liblttng-ust-java-jni
liblttng-ust-java
liburcu2
python-lttng
liblttng-ust-ctl2
libbabeltrace1
libbabeltrace-ctf1
python3-babeltrace

   Your listings seem all right; the difference is source vs binary: the source 
package liburcu builds the binary packages liburcu-dev, liburcu1 and liburcu2, 
for instance.  (I'm more used to building from source)

   Ignoring the babeltrace packages, the dependencies are such that this is the 
minimal install: liblttng-ust-dev, liblttng-ctl-dev, lttng-tools.  Optionally, 
liblttng-ust-java, python-lttng, lttng-modules-dkms.  Turns out liburcu1 is not 
connected to anything (I think it's for older releases).

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Errors compiling converted tp file

[Thibault, Daniel]

   In order to trace user-space, you must install, in sequence, the following 
 packages: userspace-rcu, lttng-ust, lttng-tools.  Was this done?

   I tried to install the right packages but there don't seem to be packages 
 named like that in either the ubuntu repository or the ppa provided by you.

 I have the following packages installed:
 lttng-tools
 liblttng-ust0
 liblttng-ust-dev
 liblttng-ust-ctl2
 liblttng-ctl0
 liburcu-dev
 liburcu2

 With all this installed, I still don't get it to work.

 Yan Grange

   The equivalencies are as follows:
* userspace-rcu (git.lttng.org) = liburcu (LTTng PPA) = liburcu1, liburcu-dev 
(Ubuntu)
* lttng-ust (git.lttng.org) = lttng-ust (LTTng PPA) = liblttng-ust0, 
liblttng-ust-dev (Ubuntu)
* lttng-tools (git.lttng.org) = lttng- tools (LTTng PPA) = lttng-tools, 
liblttng-ctl0, liblttng-ctl-dev (Ubuntu)

   You should not install from the Ubuntu repositories, as they are obsolete 
(and have been obsolete for a long time now).

   For kernel tracing, lttng-modules can be fetched from git.lttng.org or the 
LTTng PPA; the Ubuntu repository equivalent is lttng-modules-dkms (obsolete).

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Errors compiling converted tp file

[Thibault, Daniel]

--
Date: Wed, 10 Dec 2014 16:16:06 +0100

 Thanks for that.  I have asked our sysadmin to install a newer version via 
 this method. Even though he gets several severe-lloking errors in this process

 $ apt-get install liblttng-ust-dev

 Building initial module for 3.2.0-61-generic
 Errors were encountered while processing:
  lttng-modules-dkms
  Error!  Build of lttng-probe-printk.ko failed for: 3.2.0-61-generic (x86_64)

 In the make log, we find the following three lines:

 /var/lib/dkms/lttng-modules/2.5.x+stable+bzr633+pack21+201412020446~ubuntu12.04.1/build/probes/Makefile:30:
  File /usr/src/linux-headers-3.2.0-61-generic/virt/kvm/iodev.h not found. 
 Probe kvm x86-specific is disabled. Use full kernel source tree to enable 
 it.
 /var/lib/dkms/lttng-modules/2.5.x+stable+bzr633+pack21+201412020446~ubuntu12.04.1/build/probes/Makefile:142:
  Files /usr/src/linux-headers-3.2.0-61-generic/fs/btrfs/*.h not found. Probe 
 btrfs is disabled. Use full kernel source tree to enable it.
 /var/lib/dkms/lttng-modules/2.5.x+stable+bzr633+pack21+201412020446~ubuntu12.04.1/build/probes/Makefile:158:
  Files /usr/src/linux-headers-3.2.0-61-generic/fs/ext4/*.h not found. Probe 
 ext4 is disabled. Use full kernel source tree to enable it.

 The full kernel source tree is already installed. 

   Those three errors are inconsequential; they simply mean your kernel does 
not support kvm nor the btrfs and ext4 file systems (a common occurrence).

 However it actually works to create a header file from a tp file and compile 
 (and run) the code. However I now get in trouble when executing:

 $ lttng list --userspace
 Error: Unable to list UST events: Undefined command
 Error: Command error

 So I guess something still went somewhat wrong but I can't really see what.

 Yan Grange

   In order to trace user-space, you must install, in sequence, the following 
packages: userspace-rcu, lttng-ust, lttng-tools.  Was this done?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] UST improvement ideas

[Thibault, Daniel]

--
Date: Tue, 25 Nov 2014 14:04:04 -0500
From: David Goulet dgou...@ev0ke.net

 1) Having a way to use counters in the trace.

 So basically, lots of our measurements are based on timing things which 
 tracepoints are really useful for that but we also gather stuff like How 
 many elements seen of an object in the past hour?. It's doable with 
 tracepoint but when the number goes up to millions quickly, it does not 
 really scale to have a million tp for one single counter.

 The rough idea is this:

   [...]
   tracepoint_counter_inc(mycomponent, mycounter, n);
   [...]

 where n is the amount to increment the counter designated by 
 mycomponent:mycounter.

 When the buffers are flushed or/and the tracing stop, this counter could 
 simply be updated in the trace and, for instance, babeltrace could print them 
 at the beginning of the output.

The semantics of these counters has to be thought through carefully.  A means 
of setting the counter's initial value should be available (i.e. 
tracepoint_counter_set(mycomponent, mycounter, n);), and maybe also a means of 
flushing the counter (i.e. tracepoint_counter_flush(mycomponent, mycounter, 
myevent);, where mycomponent:myevent has a single-argument signature of the 
same type as the counter) ---flushing in this case means forcing a tracepoint 
event to be issued with the current counter's value as its payload.

Should counters be assigned to channels and enabled/disabled just like events?  
If a counter is assigned to multiple channels within a trace, the same value 
should transpire in each channel.  On the other hand, if the counter is 
assigned in several separate traces, the values should be independent of each 
other.  When a counter/channel/trace is disabled, should the counter ignore any 
tracepoint_counter_set/_inc/_flush commands?  Finally, what happens when an 
application dynamically unloads the provider handling the counter and later 
loads it back in?  Presumably the counter value resets to its default zero 
(here's another idea: maybe the counter's default creation value can be 
non-zero, and is set in the tracepoint template by the tracepoint-counter 
creation macros).

Maybe counters can be handled in truly event-like fashion: when a counter is 
created, set, or destroyed, an implicit event occurs (described in the 
tracepoint template by the tracepoint-counter creation macros).  Simply 
incrementing the counter does not trigger an event.  The application API is 
then decoupled from the LTTng trace, and the lttng client does not need to be 
changed at all, being unaware of counters.

Here's a strawman for discussion:

In the instrumented apps, simply include tp.h as usual, and use any or all of 
the counter API methods: tracepoint_counter_set(component, counter, value), 
tracepoint_counter_inc(component, counter, value), 
tracepoint_counter_flush(component, counter).  In the tracepoint header, the 
counter is defined like this:

TRACEPOINT_COUNTER (provider name, counter name, TPC_INITIAL_VALUE(type, 
value), TPC_FIELD( ctf_scalar(type, field name, counter name) ) )

Whenever the counter is created by the instrumented app (by any one of the 
three methods), a provider name:counter name_created event occurs.  
Whenever the counter is destroyed (the instrumented app terminates or unloads 
the provider), a provider name:counter name_destroyed event occurs.  
Whenever the counter is flushed, a provider name:counter name_report event 
occurs.  All events report the counter's value.

The counter's events cannot be called directly from the instrumented app.  On 
the lttng client side, one assigns the counter's three events to channels and 
enables/disables them as usual.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Question about TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE

[Thibault, Daniel]

--
Date: Fri, 21 Nov 2014 15:28:30 +0400
From: Eugene Ivanov e...@tbricks.com

Normally you use TRACEPOINT_EVENT_CLASS and _INSTANCE within the same
 provider, but you could theoretically have varying instances rely on
 different providers.  I guess this would allow you some flexibility in
 picking which sets of instances to enable/disable by picking which provider
 shared objects (.so) to preload or not.

Thanks for the explanation, Daniel! Unfortunately using class defined in
another provider doesn't work. I get an error about undefined
__event_probe__instance_provider_name___class_name_from_another_provider?.
Connecting it with your description, I guess it's probably a feature and
intended behaviour. Though it would be a nice feature to be able to specify
provider of class separately from provider of instance.

   Would LTTng-delvers more versed in these innards care to comment on the 
following?

   If the provider argument to the macros is not intended to ever point at 
anything else than the provider block it is declared in (the #define 
TRACEPOINT_PROVIDER line), this should be documented and ideally the macros 
should hide this implicit argument.

   On the other hand, if the intent is to allow cross-provider usage of some 
form, this also needs to be documented.  What is the recipe supposed to be?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Question about TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE

[Thibault, Daniel]

 Date: Wed, 19 Nov 2014 15:35:01 +0400
 From: Eugene Ivanov e...@tbricks.com

 I found description of TRACEPOINT_EVENT_CLASS on the website and in 
 ust-tracepoint-event.h as well, but it is not documented in the lttng-ust man 
 page.
 According the header TRACEPOINT_EVENT_INSTANCE declares an instance of a 
 tracepoint, with its own provider and name.
 Does it mean that I can define classes for usage in different providers? Why 
 do we need provider in _CLASS then?
 According the code on the first glance it seems that it is required that 
 CLASS and INSTANCE must share in same provider.

   You will also have seen that the default macro TRACEPOINT_EVENT simply 
wraps both TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE together.  When 
used separately, the TRACEPOINT_EVENT_INSTANCE must match its template's 
params; the event class then takes care of the mapping of parameters to fields 
in the event output.  This allows you to declare a single event class 
somewhere, then declare various instances that vary by name only, typically 
because they're events of the same nature but occurring in varying contexts.  
Having the trace label them under different names makes the analyst's life 
easier.

   Normally you use TRACEPOINT_EVENT_CLASS and _INSTANCE within the same 
provider, but you could theoretically have varying instances rely on different 
providers.  I guess this would allow you some flexibility in picking which sets 
of instances to enable/disable by picking which provider shared objects (.so) 
to preload or not.

   Kernel space has essentially the same macros under the names 
DECLARE_EVENT_CLASS and TRACE_EVENT, respectively.  You can see those at work 
in the lttng-modules package and in some kernel modules such as 
drivers/staging/android/binder_trace.h.  In the latter, for example, you see a 
binder_lock_class which is then instantiated as binder_lock, binder_locked, and 
binder_unlock.  These three events carry very different semantics, but they 
have precisely the same parameter signatures.  Grouping them under an event 
class avoids a lot of cutting-and-pasting and diminishes the risk of errors 
later on (e.g. if you had to modify the field layout of binder_lock and forgot 
to copy it to binder_unlock).

   Why do we need provider in _CLASS then?  Because the provider name is part 
of the fully-qualified event class name.  This allows different event classes 
(and event instances) to have the same short names within different providers.  
You would be bound to run into collisions if all the event class or event 
instance names were global.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] multiple tracing sessions using relayd

[Thibault, Daniel]

 Date: Mon, 10 Nov 2014 13:02:58 -0500
 From: J?r?mie Galarneau jeremie.galarn...@efficios.com
 To: Anand Neeli anand.ne...@gmail.com

  I tried to create same without relayd and it works. Am i missing 
  anything here?
 
  Although in the above example i'm enabling same/all events in session1 
  and session2, but i think this should work and capture same events in 
  both the sessions.

 That's the expected behaviour.

 Jérémie

   With one very important caveat: the copies of the events in each session 
will most likely bear different timestamps.  That's because the timestamps 
capture the moments at which the event data slots are reserved in the consumer 
buffers.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
 LinkedIn: http://ca.linkedin.com/in/daniel-u-thibault/
 Research Gate: https://www.researchgate.net/profile/Daniel_Thibault/

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

Re: [lttng-dev] Strange result from LTTng porting to ARM

[Thibault, Daniel]

--
Date: Wed, 12 Nov 2014 23:26:41 +0800
From: J Lin jmlin.jm...@gmail.com

 I've recently ported LTTng to ARM and I can't seem to understand what is 
 going wrong with my results. I ran a typical session with lttng enable-event 
 -k -a for test. Here are the observations:

 1. only lttng_xxx (e.g, lttng_statedump_interrupts) are recorded 2. 
 different sessions yield trace on different CPU (the system has 4) but not 
 for all 4, just 1 cpu 3. no recorded session span more than 1 second though I 
 would run sleep (i.e., 10s) between start and stop

 This leads me to believe LTTng might be dependent on something in the system 
 that isn't present. This is a customized kernel of a client. It has all 
 required configs.

 If there is a trigger mechanism after running lttng start, what would it 
 be? It seems it grabs items initially then doesn't continue. I read in one of 
 the papers that LTTng is architecture dependent. Any help is appreciated.

 Mike

   How exactly did you port LTTng to ARM?  As far as I know, you need only 
rebuild it there.  Your symptoms lead me to believe you may have not installed 
the requisite lttng-modules.  Did you test user-space tracing?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] lttngtop dependencies

[Thibault, Daniel]

Currently, the lttngtop/README mentions only the following dependencies:

* gcc 3.2 or better
* libc6 development librairies (Debian : libc6, libc6-dev) (Fedora : glibc, 
glibc)
* glib 2.22 or better development libraries (Debian : libglib2.0-0, 
libglib2.0-dev) (Fedora : glib2, glib2-devel)
* libpopt = 1.13 development libraries (Debian : libpopt-dev) (Fedora : popt)
* ncurses development libraries (Debian : libncurses5-dev)
* babeltrace = 1.2.0 development library

   However, since 19 October 2013 
(http://git.lttng.org/?p=lttngtop.git;a=commitdiff;h=16b22a0fe150f4923b9902e802bbf28bacce8d0e),
 lttngtop depends on lttng-tools (for lttng/lttng.h, lttng/lttngtop-helper.h 
and later headers, needed to handle live traces).  This must be added to the 
README (not to mention any DEBIAN/control package files).

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Writing .tp files for lttng-gen-tp

[Thibault, Daniel]

--
Date: Fri, 17 Oct 2014 21:39:21 +
From: Boisvert, Sebastien boisv...@anl.gov

 I wrote a big .tp file to define numerous tracepoints that only differ in the 
 event name.
 They all take the same arguments and they all dump the same fields.

 .tp file: 
 https://github.com/sebhtml/biosal/blob/master/engine/thorium/tracepoints/lttng/message.tp

 Is there a more compact way of doing that ?

   Sébastien
--
   In the kernel domain, one can declare a tracepoint class with 
DECLARE_EVENT_CLASS, and then use DEFINE_EVENT to instantiate the abstract 
event class into individual trace events that share a single signature.  Surely 
the same can be done in user-space?

   Looking at /usr/src/lttng-ust/include/lttng/tracepoint.h, we see there are 
TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE macros right beside 
TRACEPOINT_EVENT, so I suspect you could replace your message.tp with something 
like:

[...]
TRACEPOINT_EVENT_CLASS(
thorium_message,
thorium_event_template,
TP_ARGS(
struct thorium_message *, message
),
TP_FIELDS(
ctf_integer(int, message_number, message-number)
ctf_integer(int, message_action, message-action)
ctf_integer(int, message_count, message-count)
ctf_integer(int, message_source_actor, message-source_actor)
ctf_integer(int, message_destination_actor, message-destination_actor)
ctf_integer(int, message_source_node, message-source_node)
ctf_integer(int, message_destination_node, message-destination_node)
)
)

TRACEPOINT_EVENT_INSTANCE(
thorium_message,
thorium_event_template, 
actor_send,
TP_ARGS(
struct thorium_message *, message
)
)

TRACEPOINT_EVENT_INSTANCE(
thorium_message,
thorium_event_template, 
node_send,
TP_ARGS(
struct thorium_message *, message
)
)
[...]

   Try it and let us know.  This should be added to the lttng-gen-tp man pages 
if it works.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Writing .tp files for lttng-gen-tp

[Thibault, Daniel]

-Message d'origine-
De : Boisvert, Sebastien [mailto:boisv...@anl.gov] 
Envoyé : 20 octobre 2014 11:38

 Are TRACEPOINT_EVENT_CLASS and
 TRACEPOINT_EVENT_INSTANCE part of the LTTng-UST end user interface (are these 
 stable between release) ?

 If so, I will gladly give it a try !

   As far as I can tell, yes, these two macros seem to have been around 
forever.  I've tested them out on some demo code and they work fine.  They are 
also compatible with lttng-gen-tp.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada  
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Writing .tp files for lttng-gen-tp

[Thibault, Daniel]

-Message d'origine-
Envoyé : 20 octobre 2014 11:51

 Thanks for testing.

 I will use these.

 Can I add Suggested-by: Daniel Thibault daniel.thiba...@drdc-rddc.gc.ca 
 in our open source BIOSAL git log ?

   Absolutely!

   I also take cash, money orders, cheques and payment in kind.   :-)

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
 LinkedIn: http://ca.linkedin.com/in/daniel-u-thibault/
 Research Gate: https://www.researchgate.net/profile/Daniel_Thibault/

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

[lttng-dev] btrfs tracepoint oddity

[Thibault, Daniel]

   Something odd happens when I build lttng-modules (2.5.0-9) with an enriched 
linux-headers package (I added the btrfs, ext3, and ext4 file system headers 
from the Linux source): one of the btrfs events has a strange name.

$ sudo -H lttng list -k
[...]
btrfs_ordered_extent_start
btrfs_ordered_extent_put
__extent_writepage
btrfs_writepage_end_io_hook
btrfs_sync_file
[...]

   This can be traced to include/trace/events/btrfs.h (in the Linux kernel 
source), which has:

[...]
DEFINE_EVENT(btrfs__writepage, __extent_writepage,
[...]

instead of

[...]
DEFINE_EVENT(btrfs__writepage, btrfs_extent_writepage,
[...]

   This is a minor annoyance (it does not impede LTTng from functioning) that I 
suppose needs to be handled upstream?  No other kernel tracepoint seems to have 
an out-of-joint name.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] sessiond and consumerd for 32 and 64 bit apps

[Thibault, Daniel]

 Yes the problem looks to be with relay daemon. Tracing for 32-bit and 64-bit 
 works fine when written to local storage.
 Is there any known issue for this? or is there any work around for this.
 I will update this thread with logs of relayd with -vvv option.

 Anand Neeli

   I’ve just tested my 32+64-bit LTTng 2.3.0 installation with the relay daemon 
and it works fine:

$ sudo lttng create testing -U net://localhost
$ sudo lttng enable-channel mychannel --userspace --buffers-pid 
--tracefile-size 8388608 --tracefile-count 8
$ sudo lttng enable-event --channel mychannel --userspace --all
$ sudo lttng start
$ cd 
~/Documents/lttng-ust-2.3.0-1-32bits/usr/src/lttng-ust-2.3.0/doc/examples/drdc
$ ./sample_static
$ LD_PRELOAD=/usr/local/lib32/liblttng-ust.so ./sample_static32
$ sudo lttng destroy
$ sudo ls ~/lttng-traces/$HOSTNAME
testing-20141008-095516

   (The LD_PRELOAD can be omitted if the sample_static32 is compiled with the 
‘-Wl,-rpath,'/usr/local/lib32',--enable-new-dtags’ linker flags)

   The trace consists of the two folder sets 
ust/pid/sample_static32-13703-20141008-102156 and 
ust/pid/sample_static-13676-20141008-101417.

   Here’s how this was built (I chose to put my 32-bit libraries in 
/usr/local/lib32):

userspace-rcu-0.8.0-1.deb was deployed to 
~/Documents/userspace-rcu-0.8.0-1-32bits

In the usr/src/userspace-rcu-0.8.0 subdirectory:

$ ./bootstrap
$ ./configure --libdir=/usr/local/lib32 CFLAGS=-m32
$ make
$ sudo make install
$ sudo ldconfig

lttng-ust-2.3.0-1.deb was deployed to ~/Documents/lttng-ust-2.3.0-1-32bits

In the usr/src/lttng-ust-2.3.0 subdirectory:

$ ./bootstrap
$ ./configure --libdir=/usr/local/lib32 CFLAGS=-m32 \
   LDFLAGS=-L/usr/local/lib32
$ make
$ sudo make install
$ sudo ldconfig

LDFLAGS allows the build to find the 32-bit userspace-rcu libraries it requires.

lttng-tools-2.3.0-1.deb was deployed to ~/Documents/lttng-tools-2.3.0-1-32bits

In the usr/src/lttng-tools-2.3.0 subdirectory:

$ ./bootstrap
$ ./configure --libdir=/usr/local/lib32 CFLAGS=-m32 \
   LDFLAGS=-L/usr/local/lib32 --bindir=/usr/local/bin32 \
   --with-consumerd-only \
   --with-consumerd64-libdir=/usr/local/lib \
   --with-consumerd64-bin=/usr/local/lib/lttng/libexec/lttng-consumerd
$ make
$ sudo make install
$ sudo ldconfig

The bindir option isn’t actually used by the compilation and is indicated here 
just for completeness.  The with-consumerd64-bin and with-consumerd64-libdir 
options ensure the 32-bit lttng-tools components find the 64-bit consumer 
daemon.  Normally, the with-consumerd-only make fails because it tries to make 
too many tests; this was fixed by editing the Makefile and removing the tests 
sub-directory from the SUBDIRS variable (line 305) before running configure.  
The suppressed tests are not required in order to have a functioning 32-bit 
LTTng toolchain.

Finally, the 64-bit lttng-tools are redone to hook in the 32-bit 
lttng-consumerd.

lttng-tools-2.3.0-1.deb was deployed to ~/Documents/lttng-tools-2.3.0-1-64bits

In the usr/src/lttng-tools-2.3.0 subdirectory:

$ ./bootstrap
$ ./configure LDFLAGS=-L/usr/local/lib \
   --with-consumerd32-libdir=/usr/local/lib32 \
   --with-consumerd32-bin=/usr/local/lib32/lttng/libexec/lttng-consumerd
$ make
$ sudo make install
$ sudo ldconfig

This way, the lttng-sessiond and lttng-relayd daemons will automatically find 
and use the 32-bit lttng-consumerd if required.  No special flags need to be 
added when controlling the daemons.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ--ESFSECEV-TY3011
Gouvernement du Canada | Government of Canada 
http://www.valcartier.drdc-rddc.gc.ca/--ESFSECEV-TY3011-
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] sessiond and consumerd for 32 and 64 bit apps

[Thibault, Daniel]

De : Anand Neeli [mailto:anand.ne...@gmail.com]
Envoyé : 8 octobre 2014 16:19

 Can’t the consumerd32-libdir or consumerd32-bindir be given at run time by 
 using consumerd32-path, consumerd32-libdir or by setting env variables 
 LTTNG_CONSUMERD32_LIBDIR and LTTNG_CONSUMERD32_BIN (similarly for 64-bit)?
 Can it be changed at compile time?

 Anand Neeli
   Sure, lttng-sessiond accepts consumerd(32|64)-(libdir|path) options which in 
turn override the environment variables LTTNG_CONSUMERD(32|64)_(LIBDIR|BIN) 
variables.  Setting the with-consumerd(32|64)-(libdir|bin) configure options 
simply sets the default values for these.

   I’m curious as to why your relay daemon was misbehaving.  It should be 
unaffected by bitness, since the session daemon takes care of creating the 32- 
and 64-bitconsumer daemons and tells them where to send their event streams.  I 
noticed the lttng-relayd binaries built by a 64-bit-only installation and a 
mixed 32-64-bit one are different, so maybe something subtle was going on.  
However, when I copied the “64-bit-only” relay daemon executable over to the 
mixed environment and ran the tracing experiment again, it captured both 32- 
and 64-bit events.

   You must have somehow broken your relay daemon?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJhttp://www.travelgis.com/map.asp?addr=918V%20QSDJ 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] lttng-modules on Debian Wheezy BeagleBone Black rev. C

[Thibault, Daniel]

 arch/include/asm has a time.h but no timex.h.

   Correction:

   arch/arm/include/asm/mach has a time.h but no timex.h.

   Googling around, it seems the missing timex.h can either be ignored (by 
creating an empty file in the expected spot), or recovered from the full kernel 
source tree, at arch/arm/mach-processor/include/mach.  My problem is 
identifying the correct one, if any.  Uname -i and uname -p both return 
'unknown' for the BeagleBone Black (while running Debian Wheezy, anyway).

   These files seem to serve mostly to #define the CLOCK_TICK_RATE, with values 
such as 512000, 100 and 3800, 4000.  Some mach-processor 
directories do not have an include sub-directory.  Other mach-processor cases 
comment the CLOCK_TICK_RATE value as 'bogus'.  I'll try to resolve this 
tomorrow.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada 
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] sessiond and consumerd for 32 and 64 bit apps

[Thibault, Daniel]

--
Date: Tue, 7 Oct 2014 23:12:47 +0530
From: Anand Neeli anand.ne...@gmail.com

 To add more details to my query.
 I want to trace both 32-bit and 64-bit apps.
 For this i launched sessiond with 32 and 64 bit paramaters of consumerd.
 (shown below)

 i see that 64-bit app's are able to log whereas 32-bit app's are not logging.

 Below is the output with -vvv, can anyone help me to find the problem here.

 mysystem   # find /usr/lib/ -name *lttng*
 /usr/lib/liblttng-ctl.so.0
 /usr/lib/liblttng-ctl.so.0.0.0
 /usr/lib/liblttng-ust.so.0
 /usr/lib/liblttng-ust.so.0.0.0
 /usr/lib/liblttng-ust-ctl.so.2
 /usr/lib/liblttng-ust-ctl.so.2.0.0
 /usr/lib/liblttng-ust-cyg-profile.so.0
 /usr/lib/liblttng-ust-cyg-profile.so.0.0.0
 /usr/lib/liblttng-ust-cyg-profile-fast.so.0
 /usr/lib/liblttng-ust-cyg-profile-fast.so.0.0.0
 /usr/lib/liblttng-ust-dl.so.0
 /usr/lib/liblttng-ust-dl.so.0.0.0
 /usr/lib/liblttng-ust-fork.so.0
 /usr/lib/liblttng-ust-fork.so.0.0.0
 /usr/lib/liblttng-ust-libc-wrapper.so.0
 /usr/lib/liblttng-ust-libc-wrapper.so.0.0.0
 /usr/lib/liblttng-ust-pthread-wrapper.so.0
 /usr/lib/liblttng-ust-pthread-wrapper.so.0.0.0
 /usr/lib/liblttng-ust-tracepoint.so.0
 /usr/lib/liblttng-ust-tracepoint.so.0.0.0
 /usr/lib/lttng
 /usr/lib/lttng/libexec/lttng-consumerd

 mysystem   # find /usr/lib64/ -name *lttng*
 /usr/lib64/libbabeltrace-lttng-live.so.1
 /usr/lib64/libbabeltrace-lttng-live.so.1.0.0
 /usr/lib64/liblttng-ctl.so.0
 /usr/lib64/liblttng-ctl.so.0.0.0
 /usr/lib64/liblttng-ust.so.0
 /usr/lib64/liblttng-ust.so.0.0.0
 /usr/lib64/liblttng-ust-ctl.so.2
 /usr/lib64/liblttng-ust-ctl.so.2.0.0
 /usr/lib64/liblttng-ust-cyg-profile.so.0
 /usr/lib64/liblttng-ust-cyg-profile.so.0.0.0
 /usr/lib64/liblttng-ust-cyg-profile-fast.so.0
 /usr/lib64/liblttng-ust-cyg-profile-fast.so.0.0.0
 /usr/lib64/liblttng-ust-dl.so.0
 /usr/lib64/liblttng-ust-dl.so.0.0.0
 /usr/lib64/liblttng-ust-fork.so.0
 /usr/lib64/liblttng-ust-fork.so.0.0.0
 /usr/lib64/liblttng-ust-libc-wrapper.so.0
 /usr/lib64/liblttng-ust-libc-wrapper.so.0.0.0
 /usr/lib64/liblttng-ust-pthread-wrapper.so.0
 /usr/lib64/liblttng-ust-pthread-wrapper.so.0.0.0
 /usr/lib64/liblttng-ust-tracepoint.so.0
 /usr/lib64/liblttng-ust-tracepoint.so.0.0.0
 /usr/lib64/lttng
 /usr/lib64/lttng/libexec/lttng-consumerd

   Presumably you also have 32- and 64-bit versions of userspace-rcu 
(liburcu*)?  There should also be two versions of libpopt.so, incidentally.

   Were the 32- and 64-bit compilations of lttng-tools cross-referenced?  That 
is to say, 32-bit lttng-tools should have been configured with the 
with-consumerd-only, with-consumerd64-libdir, and with-consumerd64-bin options, 
while 64-bit lttng-tools should have been configured with the 
with-consumerd32-libdir and with-consumerd32-bin options.  This is important 
for lttng-relayd to be made correctly.

 mysystem # lttng-relayd -d

 mysystem # lttng-sessiond \
 --consumerd32-path /usr/lib/lttng/libexec/lttng-consumerd \
 --consumerd32-libdir /usr/lib/ \
 --consumerd64-path /usr/lib64/lttng/libexec/lttng-consumerd \
 --consumerd64-libdir /usr/lib64/ \
 -b --no-kernel -vvv

 [...]
 DEBUG2 [1203/1203]: UST consumer 32 bits err path: 
 /var/run/lttng/ustconsumerd32/error (in main() at main.c:4709)
 DEBUG2 [1203/1203]: UST consumer 32 bits cmd path: 
 /var/run/lttng/ustconsumerd32/command (in main() at main.c:4711)
 DEBUG2 [1203/1203]: UST consumer 64 bits err path: 
 /var/run/lttng/ustconsumerd64/error (in main() at main.c:4720)
 DEBUG2 [1203/1203]: UST consumer 64 bits cmd path: 
 /var/run/lttng/ustconsumerd64/command (in main() at main.c:4722)
 [...]
 Warning: No tracing group detected
 DEBUG2 [1203/1203]: Creating consumer directory: 
 /var/run/lttng/ustconsumerd64 (in set_consumer_sockets() at main.c:4343)
 DEBUG2 [1203/1203]: Creating consumer directory: 
 /var/run/lttng/ustconsumerd32 (in set_consumer_sockets() at main.c:4343)
 DEBUG3 [1203/1203]: Session daemon client socket 8 and application socket 9 
 created (in init_daemon_socket() at main.c:4209)
 [...]

 mysystem # lttng  --no-sessiond create mysession --live 20 -U 
 net://localhost
 [...]
 Session mysession created.
 Traces will be written in net://localhost
 Live timer set to 20 usec

 mysystem #  lttng enable-channel mychannel --userspace --buffers-pid -s 
 mysession --tracefile-size 8388608 --tracefile-count 8
 [...]
 DEBUG3 [1203/1206]: Copy session consumer subdir 
 mysystem_node//mysession-20141007-101236//ust (in copy_session_consumer() at 
 main.c:2484)
 DEBUG1 [1203/1206]: Spawning consumerd (in spawn_consumerd() at main.c:2158)
 DEBUG2 [1203/1206]: Consumer pid 1214 (in start_consumerd() at main.c:2340)
 DEBUG2 [1203/1206]: Spawning consumer control thread (in start_consumerd() at 
 main.c:2343)
 DEBUG3 [1203/1204]: [ht-thread] Polling on 2 fds. (in thread_ht_cleanup() at 
 ht-cleanup.c:64)
 DEBUG1 [1214/1214]: Using 64-bit UST consumer at: 
 /usr/lib64/lttng/libexec/lttng-consumerd (in 

Re: [lttng-dev] sessiond and consumerd for 32 and 64 bit apps

[Thibault, Daniel]

   One other thing: try the same test without using lttng-relayd, that is to 
say, write the test trace to local storage.  If that trace captures both 32- 
and 64-bit events, the problem is with your relay daemon.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada 
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] ARMv7 Beagle Bone Black and the dmb instruction

[Thibault, Daniel]

   This is a return to an issue first mentioned here in June 2014 (Debian 
specific userspace RCU configure override (ARMv7 Beagle Bone Black)).

   I'm trying to install TTng on an ARMv7 Beagle Bone Black.  Lttng-modules 
installs but adds nothing because the kernel has no CONFIG_TRACEPOINTS flag.  
So this will be a pure user-space installation.  Userspace-rcu installs without 
trouble, although I note that its configure log states checking for dmb 
instruction... yes.  Lttng-ust, however, fails completely to install.  I note 
that its configure log makes no mention of a dmb instruction -an omission?

   The make fails at 
/usr/src/lttng-ust-2.5.0/libringbuffer/libringbuffer_la-ring_buffer_frontend.lo

CC libringbuffer_la-ring_buffer_frontend.lo
/tmp/ccsyYAoj.s: Assembler messages:
/tmp/ccsyYAoj.s:2678: Error: selected processor does not support ARM mode `dmb'
/tmp/ccsyYAoj.s:2692: Error: selected processor does not support ARM mode `dmb'
/tmp/ccsyYAoj.s:2725: Error: selected processor does not support ARM mode `dmb'
...
(22 more such errors)
...
Make[2]: *** [libringbuffer_la-ring_buffer_frontend.lo] Error 1

userspace-rcu is 0.8.0-64-(0.8.4-21)-718eb63
lttng-ust is 2.5.0-10-501f677

'Angstrom GNU/Linux v2012.12 (Core edition)' on kernel '3.8.13'.  No systemtap, 
no Java or JNI.
Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] ARMv7 Beagle Bone Black and the dmb instruction

[Thibault, Daniel]

   Oops.  I had stopped too early in looking up the earlier discussion of this 
problem.

   Both /usr/local/include/urcu/config.h and 
/usr/src/userspace-rcu-0.8.0/urcu/config.h have '#define 
CONFIG_RCU_ARM_HAVE_DMB 1' and commenting this out may allow the makes to 
complete.

De : Jon Bernard [mailto:jbern...@debian.org] 
Envoyé : 5 juin 2014 14:30

 It sounds like you might be hitting the same issue that I had.  When building 
 urcu on this particular host, ./configure will detect an armv7 target even 
 though userland is armv4.
 I was able to get around this by explicitly passing '--build' and '--host' 
 flags to configure.

 In my particular case, the build machine is v7 hardware running a v7 kernel 
 but with a v4 userland.  You can confirm this with
gcc -dumpmachine

# gcc -dumpmachine 
arm-angstrom-linux-gnueabi

   I have no idea how this 'arm-angstrom-linux-gnueabi' relates to armv4 
user-space vs. armv7 kernel space.

   Jon, could you elaborate on the --build and --host fix?
 
Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Userspace privilege

[Thibault, Daniel]

--
Date: Sat, 13 Sep 2014 05:33:29 +0800
From: Manikandan Govindaswamy ma...@vestas.com

 We have a busybox version target and starting the lttng on root privilege.

 The kernel traces  works fine and we could get all the traces, we have 
 application which needs root privilege to start some part of services and 
 also has tracepoints in it, so have to run my application from root ( part of 
 tracing group).

 When I start the another tracing from an user account who is part of tracing 
 group, if I run the lttng list, it opens a new session for the user?

 So could not possible to see the user space tracepoints which I've started 
 from root( though it's part of tracing group).

 If the user also part of tracing group then the session started by root 
 should have been used by the user trace list, and possible to see the 
 tracepoints or not?

 GMK.
--
   I'm not sure I understand your question correctly, but I'll try to answer it 
anyway.

   Your setup sounds right: you have lttng-sessiond running as a root service, 
and your tracing users are part of the tracing group.

   Sessions are per-user objects, so one user cannot control another's sessions 
(unless he impersonates that user using 'sudo -H -u username lttng ...').

   As long as you are a member of the tracing group, you will see all available 
user-space tracepoints, from all user-spaces, even root's.  Two tracing users 
can create individual sessions, each of which can subscribe to the same 
user-space tracepoints.  There will be discrepancies in the time-stamps of the 
events in either trace, however (that is to say, the same event will register 
under slightly different timestamps in either user's trace).

   If you want two users to control the same root session (necessary in order 
to see root's user-space tracepoints), they need to both impersonate root.  
This is done by systematically issuing 'sudo -H lttng ...' commands.

   For more details, see section 3.4 of the LTTng Comprehensive User's Guide 
(soon to be available; either I or Christian Babeux can send you an advance 
copy if you'd like).

   If the above does not address your concerns, please explain in detail with 
sample session extracts.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] lttng-bash_completion

[Thibault, Daniel]

The lttng-tools.git file extras/lttng-bash_completion is incomplete since the 
addition the load and save commands to LTTng's repertoire.  The missing 
routines (inserted between _lttng_cmd_list() and _lttng_cmd_setsession()) would 
be:

_lttng_cmd_load() {
options=$(lttng load --list-options)

case $cur in
-*)
_lttng_complete_options
return
;;
*)
_lttng_complete_sessions
return
;;
esac
}

_lttng_cmd_save() {
options=$(lttng save --list-options)

case $cur in
-*)
_lttng_complete_options
return
;;
*)
_lttng_complete_sessions
return
;;
esac
}

   I'll let someone else generate the patch.

   Oh, and there's a bug with those two commands.  See bug #835.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] Odd file and path in lttng-tools tarball

[Thibault, Daniel]

   In the almost-current tarball for lttng-tools (2.5.0-rc2-93, 6e7241f) 
(current version is 2.5.0-rc2-101, 883d80f), there is an odd file present, 
presumably a leftover from testing:

tests/regression/tools/save-load/ /tmp/tmp.eAJ1f0oCZE/test-42/save-42.lttng

   (Note the folder named ' ')

   Surely that does not belong?  It has been there since the 24 Mar 2014 
e02b109 commit (2.4.0-rc2-184).

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Odd file and path in lttng-tools tarball

[Thibault, Daniel]

-Message d'origine-
De : David Goulet [mailto:dgou...@efficios.com] 
Envoyé : 10 septembre 2014 16:24

  tests/regression/tools/save-load/ 
  /tmp/tmp.eAJ1f0oCZE/test-42/save-42.lttng

 Hrm ... I don't see that in any 2.5.0-rcX tarball...

 Maybe it was created on your side? Is the tarball matching the gpg signature 
 also once downloaded?

 David

   Nope, not a local artefact.  You can see it in the gitweb interface 
everywhere.  Starting at for instance 
http://git.lttng.org/?p=lttng-tools.git;a=tree;f=tests/regression/tools/save-load;h=b792f337a7d13cf17b519b02de88db4d73b215f6;hb=883d80f9e038060bccf0512679eb366c7b245d14
 you can spot the ' ' folder deep inside of which lies the save-42.lttng

   (Just in case the URL gets mangled by e-mail filters, here it is in bits:)
http://
git.lttng.org/
?p=lttng-tools.git;
a=tree;
f=tests/regression/tools/save-load;
h=b792f337a7d13cf17b519b02de88db4d73b215f6;
hb=883d80f9e038060bccf0512679eb366c7b245d14

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] babeltrace 1.2.2 and python3

[Thibault, Daniel]

   The babeltrace 1.2.2 README suggests the python3-dev package and states 
configure need only be called with the enable-python-bindings option.

   However, my configure log (on a system with python3-dev (and therefore 
python3) and swig2.0 installed) reads in part:

checking for swig... no
checking for swig2.0... /usr/bin/swig2.0
checking SWIG version... 2.0.4
checking for SWIG library... /usr/share/swig2.0
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/dist-packages
checking for python extension module directory... 
${exec_prefix}/lib/python2.7/dist-packages
checking for python2.7-config... /usr/bin/python2.7-config
checking python include flags... -I/usr/include/python2.7 
-I/usr/include/python2.7

   I get the impression the wrong version of python is being bound to.  Is 
this what the export of PYTHON and PYTHON_CONFIG is meant to fix?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] babeltrace 1.2.2 and python (more)

[Thibault, Daniel]

   Okay, I've got Python3 and Swig2.0 installed, now I try to make babeltrace 
1.2.2.

   Here is the bootstrap log:

+ '[' '!' -e config ']'
+ mkdir config
+ libtoolize --force --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
libtoolize: copying file `config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
+ autoreconf -i
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
libtoolize: copying file `config/config.guess'
libtoolize: copying file `config/config.sub'
libtoolize: copying file `config/install-sh'
configure.ac:33: error: possibly undefined macro: AC_MSG_ERROR
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

   No big surprise there, except the suspicious possibly undefined macro.

   Next I launch configure, setting PYTHON and PYTHON_CONFIG beforehand:

checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/bin/sh: /usr/src/babeltrace-1.2.2/config/missing: No such file or directory
configure: WARNING: `missing' script is too old or missing
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... none
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) 
-std=gnu99
checking whether make sets $(MAKE)... (cached) yes
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc -std=gnu99... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands +=... yes
checking how to convert x86_64-unknown-linux-gnu file names to 
x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain 
format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no
checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC
checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes
checking if gcc -std=gnu99 static flag -static works... yes
checking if gcc -std=gnu99 supports -c -o file.o... yes
checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes
checking whether the gcc -std=gnu99 linker (/usr/bin/ld -m elf_x86_64) supports 
shared libraries... yes
checking whether -lc should be explicitly linked in... 

Re: [lttng-dev] [PATCH lttng-tool] Mi save/load: add option to indent or not on config writer creation

[Thibault, Daniel]

--
Date: Wed, 06 Aug 2014 11:34:39 -0400
From: Alexandre Montplaisir alexmon...@voxpopuli.im
To: Simon Marchi simon.mar...@polymtl.ca,  Jonathan Rajotte Julien 
jonathan.r.jul...@gmail.com

On 08/06/2014 10:49 AM, Simon Marchi wrote:
 Just by curiosity, did you manage to put a number on that performance impact?

50
--

   Fifty what?  Furlongs per fortnight?  If dimensionless, what is it?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [PATCH lttng-tool] Mi save/load: add option to indent or not on config writer creation

[Thibault, Daniel]

--
Date: Thu, 07 Aug 2014 11:47:59 -0400
From: Alexandre Montplaisir alexmon...@voxpopuli.im
Re: Message-ID: 53e39faf.9060...@voxpopuli.im

 I was expecting Jonathan to explain it further in his upcoming reply ;)

 But from the numbers I've seen from his benchmark, it was overall 50 
 times faster when using the minified XML than using the pretty-printed 
 one.
 Mainly from:
 - Not having to concatenate all the outputted strings into one
 - Not having to iterate (MANY times) on empty XML nodes

 Alexandre
--
   Fifty times faster!?  Impressive.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Enable UST probes only in specific process

[Thibault, Daniel]

--
Date: Wed, 30 Jul 2014 17:58:25 +0400
From: Dmitri Shubin s...@tbricks.com

 Is it possible to enable user-space tracepoint in specific process (of given 
 PID)?

 AFAIU
 lttng enable-event -u prov:probe --filter '$ctx.vpid==12345'
 enables probe for all processes and then drops unmatched.

 In my case I'm doing rather heavyweight thing in probe (getting stack
 trace) and want to do that only in the process of interest.

 Is it possible?

 The only way I can do it now is playing with LTTNG_HOME variable setting it 
 to different paths for each process.

   I do believe that the filter drops the event before it starts resolving its 
arguments, so filtering should be enough.  Someone more familiar with the 
internals of LTTng should set us straight either way.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] User-space events not creating logs

[Thibault, Daniel]

--
Date: Mon, 28 Jul 2014 14:35:11 -0400
From: Jérémie Galarneau jeremie.galarn...@efficios.com
To: RGIAS MUG rajhindun...@gmail.com
Cc: lttng-dev@lists.lttng.org lttng-dev@lists.lttng.org

 Is this reproductible on stable 2.5?

 Jérémie

 On Mon, Jul 28, 2014 at 1:36 AM, RGIAS MUG rajhindun...@gmail.com wrote:
  I am using the lttng (LTTng Trace Control) 2.3.1 - Dominus Vobiscum.
  I have attached the log file with lttng-sessiond and sample user space 
  tracing application with full verbosity option.
 
 The User space tracing events logs were not available. Same 
  thing when i tried in ubuntu, there i am able to see some message 
  communications which was not present in my linux machine having 3.10 kernel.

   Any chance the instrumented application (./ackermann) is not emitting events?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [RFC] lttng-modules system call tracing filtering

[Thibault, Daniel]

--
Date: Sat, 19 Jul 2014 21:39:23 + (UTC)
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Cc: Julien Desfossez jdesfos...@efficios.com

 For the curious, I implement this filtering with a per-channel bitmap that 
 represents which system calls to trace.
 We might need to double-check that I got the NR_syscalls right for each 
 architecture, especially those with
 compatibility system call tables (64-bit archs having 32-bit compat 
 syscalls). For the common case (all system calls
 are traced), the pointer to the array is NULL, so this is a simple pointer 
 check, which is less expensive cache-wise
 than looking up within the bitmap.

 As far as lttng-tools is concerned, what is a bit different is that system 
 calls don't each get a file descriptor assigned, 
 unlike other tracepoint events. Therefore, we interact with them at the 
 channel level. If we can find a way to send 
 the disable-event command directly to the channel, with the new 
 u.syscall.disable flag I added to the lttng ABI, 
we should be able to use disable-event with syscalls.

 However, I'm not sure how deeply we need to modify lttng-tools for this.

 Mathieu

   Why is the filter per-channel?  Last time I checked, syscalls could only be 
assigned once per session, therefore there would only be a need for a 
per-session filter bitmap.  Of course, if the intent is to allow syscalls to be 
potentially multiply assigned, like user-space events are, then this is the 
right way to go.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] LTTng not generating trace contents

[Thibault, Daniel]

--
Date: Sun, 6 Jul 2014 18:49:51 -0400
From: Shariyar syed.shari...@gmail.com

 I am having a problem in generating a kernel trace using the latest LTTng on 
 Ubuntu 12.04.
 It was working fine previously but when I updated LTTng it stopped generating 
 the trace contents. I did an uninstall and reinstall but it didn't work 
 either.
--

   Please define what you mean by the latest LTTng.  What are the versions?  
($ lttng --version, $ lttng-sessiond --version)

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] LTTng not generating trace contents

[Thibault, Daniel]

--
Date: Mon, 7 Jul 2014 13:43:12 -0400
From: Shariyar syed.shari...@gmail.com
Subject: Re: [lttng-dev] LTTng not generating trace contents

 lttng --version,
lttng (LTTng Trace Control) 2.4.1 - ?poque Opaque

 lttng-sessiond --version
2.4.1

 I removed all LTTng packages from the system by manually searching in dpkg 
 and reinstalled it as follows:
 sudo apt-get install lttng-tools lttng-modules-dkms babeltrace

 The ppa in the system is: http://ppa.launchpad.net/lttng/ppa/ubuntu

   What of the liburcu, python-lttng, liblttng-ctl0, liblttng-ctl-dev packages? 
 I also presume lttng-ust is not involved?  (liburcu is a prime suspect because 
both kernel and user-space tracing depend on it)

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Simple question about tracepoint defs

[Thibault, Daniel]

--
Date: Wed, 2 Jul 2014 02:02:25 -0400
From: Sandeep K Chaudhary babbusandy2...@gmail.com

 Is it not possible to have two or more trace-point definitions in the same 
 header file?

 Reading from the manual[1] as

 There can be an arbitrary number of tracepoint providers within an
 application, but they must each have their own provider name. Duplicate
 provider names are not allowed.,

I get the idea that it is not possible since each tracepoint provider
needs to have unique name, and therefore, should be in a different
header file.

Please confirm if this is the case.

 It would be much better for me if it is possible to have multiple
 trace-point definitions in the same header file.

 [1] https://lttng.org/files/doc/man-pages/man3/lttng-ust.3.html

   Each tracepoint provider can provide a number of tracepoints.  Ideally, each 
tracepoint header should cover a single tracepoint provider -otherwise you'd 
end up with two tracepoint providers in lockstep, which is much the same as 
regrouping their tracepoints under a single tracepoint provider, except with 
extra overhead.
   Think of the tracepoint provider as the shared object that implements its 
tracepoints.  It is a container for tracepoints, very much like a file system.  
You can have two different tracepoints bearing the same name (identifier) as 
long as they are in different tracepoint providers, very much like you can have 
two different files with the same name as long as they are in different folders.
   I hope this clarifies things.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] How to check is tracepoint is currently enabled (UST)

[Thibault, Daniel]

--
Date: Sun, 22 Jun 2014 19:27:31 +0400
From: Dmitri Shubin s...@tbricks.com

 In dtrace it's possible to check if some probe is currently enabled or not 
 (to avoid argument preparation for disabled probes).
 But I'm unable to find similar feature in lttng-ust (at least it's not 
 mentioned in lttng-ust man page).

 Am I missed it or it's not implemented on purpose?

   Use the list command.  A command such as 'lttng list session_name' will 
list the known events and their enabled/disabled status.  You can filter the 
command's output by specifying a domain (--userspace) and/or a channel 
(--channel channel_name).  For example:

(begin example)
$ lttng create some_session
Session some_session created.
Traces will be written in /home/username/lttng-traces/ 
some_session-20140625-102709
$ lttng enable-event -u some_event
UST event some_event created in channel channel0
$ lttng list some_session -u --channel channel0
Tracing session some_session: [inactive]
Trace path: /home/username/lttng-traces/ some_session-20140625-102709

=== Domain: UST global ===

Buffer type: per UID

- channel0: [enabled]

Attributes:
  overwrite mode: 0
  subbuffers size: 131072
  number of subbufers: 4
  switch time interval: 0
  read time interval: 0
  output: mmap()

Events:
  some_event (type: tracepoint) [enabled]
(end example)

   You can take a look at /usr/src/lttng-tools/src/bin/lttng/commands/list.c to 
see how the information is obtained.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] trace time out of order

[Thibault, Daniel]

--
Date: Wed, 25 Jun 2014 15:15:50 +0800
From: zhenyu.ren zhenyu@aliyun.com

   I traced my rpc application. On the server side ,a thread reads a request 
 from the socket and push the workitem to a queue (pushWorkItem tracepoint 
 after queuing), another thread will get the workitem from queue and process 
 it (ProcessWorkItem tracepoint here). However, in the trace log,I saw the 
 ProcessWorkItem before pushWorkItem. Is this a clock issue?
--

   See http://bugs.lttng.org/issues/614.  This may be what you're running into.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Debian specific userspace RCU configure override (ARMv7 Beagle Bone Black)

[Thibault, Daniel]

   Further progress with LTTng on Beagle Bone Black.  Having forced 
userspace-rcu to ignore the dmb instruction (CONFIG_RCU_ARM_HAVE_DMB 
undefined), lttng-tools installs in the no-kernel, no-user-space case.  It also 
installs in the just-user-space case, but there is something potentially wrong 
with lttng-ust.  Testing the lttng-modules cases will have to wait until I get 
a new BBB kernel built that has CONFIG_TRACEPOINTS turned on.

   The dmb instruction problem still stands.

   lttng-userspace emits a long list of warnings during its make:

CC lttng-ust-malloc.lo
In file included from ../include/lttng/ust-tracepoint-event.h:367:0,
   from ../include/lttng/tracepoint-event.h:62,
   from ust_libc.h:93,
   from lttng-ust-malloc.c:29:
././ust_libc.h: In function '__event_prepare_filter_stack__ust_libc___malloc':
././ust_libc.h:35:1: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
...

   This recurs on five lines.

   Despite this, sample user-space events are captured as expected.  Babeltrace 
also installs, and the trace looks okay.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC) Cyber sécurité pour les missions essentielles (CME) | 
Mission Critical Cyber Security (MCCS) RDDC - Centre de recherches de 
Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada 
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Debian specific userspace RCU configure override (ARMv7 Beagle Bone Black)

[Thibault, Daniel]

   Recall that building lttng-ust on a Beagle Bone Black (Angstrom GNU/Linux 
 v2012.12 (Core edition) on kernel 3.8.13), 
the make fails at the CCLD of libringbuffer_la-ring_buffer_frontend.lo with an 
unexpected (and so far unexplained) 
group of Error: selected processor does not support ARM mode 'dmb' (25 
times).

 [...]
   At this point I can only try lttng-tools in its kernel tracing only mode. 
  [...]

   I run into trouble quickly, however.  The CC of 
 common/hashtable/rculfhash.lo runs into Error: selected processor 
does not support ARM mode 'dmb' (8 times).  The make aborts at this point.

   Progress on this front.  I did one thing: I edited 
userspace-rcu/urcu/arch/arm.h to comment out the #ifdef CONFIG_RCU_ARM_HAVE_DMB 
defines so that userspace-rcu builds dmb-less.  Once rebuilt and 
re-installed, I can then move on to try lttng-tools again, and this time it 
passes the rculfhash.lo step.  It dies much later for a completely unrelated 
reason which I expect to fix shortly.  At this point I also expect a rebuild of 
lttng-ust would succeed.

   So it looks like the problem is that the makefiles of lttng-tools and 
lttng-ust somehow impose too strong an architecture constraint on their linker 
(i.e. dmb-less generic ARM instead of ARMv7 with dmb).

   I hope this helps.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC) Cyber sécurité pour les missions essentielles (CME) | 
Mission Critical Cyber Security (MCCS) RDDC - Centre de recherches de 
Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada 
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Debian specific userspace RCU configure override (ARMv7 Beagle Bone Black)

[Thibault, Daniel]

--
 Date: Thu, 12 Jun 2014 13:51:06 +
   Progress on this front.  I did one thing: I edited 
 userspace-rcu/urcu/arch/arm.h to comment 
out the #ifdef CONFIG_RCU_ARM_HAVE_DMB defines so that userspace-rcu builds 
dmb-less.  
Once rebuilt and re-installed, I can then move on to try lttng-tools again, 
and this time it passes 
the rculfhash.lo step.  It dies much later for a completely unrelated reason 
which I expect to fix 
shortly.  At this point I also expect a rebuild of lttng-ust would succeed.

   Turns out this new make error is obscure (only 8 hits in Google, 3 of which 
are in Chinese).

make[5]: Entering directory 
'/usr/src/lttng-tools-2.3.0/src/lib/lttng-ctl/filter'
  LEX  filter-lexer.c
flex: fatal internal error, exec failed
make[5]: *** [filter-lexer.c] Error 141

   It turns out /usr/bin/flex is unusable on the BBB's Angstrom distribution!  
It is only runnable in calls like 'flex --help' or 'flex --version'.  As soon 
as you try to process any .l file, it will choke with an error 141.  This is 
because /usr/bin/flex uses a hard-wired reference to the m4 executable where it 
lay on the machine where the Angstrom image was cross-compiled!  (Thanks to Rob 
Clark for finding this out, 
http://gstreamer-devel.966125.n4.nabble.com/Installation-error-td969071.html)  
The ugly but simple fix is to create a symbolic link at the place flex looks 
for m4:

# mkdir -p 
/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/x86_64-linux/usr/bin
# ln -s /usr/bin/m4 
/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/x86_64-linux/usr/bin/m4

   Equivalently, invocations of flex must be preceded by setting the 
environment variable M4 = /usr/bin/m4.  Which is what userspace-rcu must 
somehow do to actually install without tripping over this bug.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada 
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [PATCH lttng-ust] Fix: remove weak attribute from __start___tracepoints_ptrs and __stop___tracepoints_ptrs

[Thibault, Daniel]

--
Date: Tue, 10 Jun 2014 09:13:54 +0200

 Does it work well if the program and/or libraries do the following:

 - they include tracepoint.h,
 - but they don't contain any tracepoint (so there is technically no
_tracepoint_ptrs section)

 Has this case been tested ? I remember that the weak was there for this
 peculiar corner case.

I tested it exactly the way you described, and yes, it works.
*HOWEVER*, if prior to including tracepoint.h the program also #defines 
TRACEPOINT_DEFINE, *THEN* we have the problem you described:

root@kmeter1:~# cat foo.c

#define TRACEPOINT_DEFINE
#include lttng/tracepoint.h

int main(void)
{
   printf(Hello world!\n);
}
root@kmeter1:~# gcc foo.c -llttng-ust -ldl
/tmp/cc92SYHX.o: In function `__tracepoints__ptrs_init':
foo.c:(.text+0x39a): undefined reference to `__stop___tracepoints_ptrs'
foo.c:(.text+0x39e): undefined reference to `__stop___tracepoints_ptrs'
[...]
/tmp/cc92SYHX.o:foo.c:(.text+0x44a): more undefined references to 
`__start___tracepoints_ptrs' follow
/usr/lib/gcc/powerpc-linux/4.7.2/../../../../powerpc-linux/bin/ld: 
a.out: hidden symbol `__stop___tracepoints_ptrs' isn't defined
/usr/lib/gcc/powerpc-linux/4.7.2/../../../../powerpc-linux/bin/ld: final 
link failed: Bad value
collect2: error: ld returned 1 exit status

Re-adding the weak attribute fixes this (though it leaves us with a 
much bigger issue, in my opinion).

However, I'm not sure whether:

a) this is really a use case (defining TRACEPOINT_DEFINE and then not 
really defining any), and even so, whether

b) what we have with the weak attribute is really what we want. In the 
end, we would be defining a function with __attribute__((constructor)) 
 (oh wait, potentially even more than one!) without actually having any 
tracepoint available. OK, the above complaints are probably not the most 
intuitive in the world, but isn't that better than an application 
silently failing (to provide any tracepoint) at runtime?

After all, the issue with the above messages is about the linker trying 
to resolve those symbols; but that's because they are used by 
__tracepoints__ptrs_init() and friends, not because they are merely 
declared.

Any thoughts?

Gerlando
--

   If the issue is to protect against TRACEPOINT_DEFINE not being 'fulfilled' 
before hitting lttng/tracepoint.h, maybe tracepoint.h should check for 
TRACEPOINT_PROVIDER in addition to TRACEPOINT_DEFINE.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Debian specific userspace RCU configure override

[Thibault, Daniel]

--
Date: Wed, 28 May 2014 14:10:50 -0400

 As I currently understand, the debian build problem is that although the
 package is compiled on armv7 hardware, it is expected to target armv4t.
 And this is not correctly detected at configure-time.  The folks on
 #debian-arm suggested that this could be solved in configure.ac.  I can
 explicitly pass '--build target' to ./configure to get around this,
 but arm users that build from source will need to remember this.

 Jon
--
   I need to revive this thread.  Although the original build failure may have 
been on ARMv7 wanting ARMv4, I've run into the same failure with a pure ARMv7 
architecture.  Specifically, Beagle Bone Black.

   I built userspace-rcu without trouble (except for that clock business 
reported earlier), but when I then tried to build lttng-ust, I ran into the 
same 'Error: selected processor does not support ARM mode `dmb'.  Taking a look 
at the userspace-rcu and lttng-ust config.logs, they *both* report 'uname -m = 
armv7l'.  The core tests *both* report a build system type of 
'armv7l-unknown-linux-gnueabi'.  However, userspace-rcu tests for dmb and finds 
it, while lttng-ust omits this test.

   The make error occurs during the CCLD of libringbuffer.la.

   Besides the make, config and configure logs, what should I post here?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Documentation Links broken?

[Thibault, Daniel]

--
Date: Wed, 4 Jun 2014 23:05:05 +
From: Randy Juillard randyjuill...@w5tech.com

 Seems that your links for the documentation are broke on the web page:
https://lttng.org/ust

 Randy Juillard
--
   Nope, the links are fine.  It's the web pages' contents which are broken.  
They are all time-stamped June 2.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Debian specific userspace RCU configure override

[Thibault, Daniel]

-Message d'origine-
De : Jon Bernard [mailto:jbern...@debian.org] 
Envoyé : 5 juin 2014 14:30

 It sounds like you might be hitting the same issue that I had.  When building 
 urcu on this particular host, ./configure will detect an armv7 target even 
 though userland is armv4.
 I was able to get around this by explicitly passing '--build' and '--host' 
 flags to configure.  There is also a pre-built armel deb for the latest 
 version of urcu at:

https://packages.debian.org/sid/armel/liburcu2/download

 In my particular case, the build machine is v7 hardware running a v7 kernel 
 but with a v4 userland.  You can confirm this with

gcc -dumpmachine

 Maybe this will help, I'm curious to know how it goes.

 Jon

# gcc -dumpmachine 
arm-angstrom-linux-gnueabi

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Debian specific userspace RCU configure override

[Thibault, Daniel]

-Message d'origine-
De : Mathieu Desnoyers [mailto:mathieu.desnoy...@efficios.com] 
Envoyé : 5 juin 2014 15:01

The make error occurs during the CCLD of libringbuffer.la.

   Correction: it occurs during the CC of 
libringbuffer_la-ring_buffer_frontend.lo

Both /usr/local/include/urcu/config.h and 
 /usr/src/userspace-rcu-0.8.0/urcu/config.h have '#define
CONFIG_RCU_ARM_HAVE_DMB 1'.  So does 
 /usr/src/userspace-rcu-0.8.0/config.h.  The only config.h *not* to have
that #define is /usr/src/lttng-ust-2.3.0/config.h.  Could it be the 
 libringbuffer make used the latter?

 This define is specific to urcu config.h. It does not (and should not) exist 
 in UST config.h.

 Mathieu

   Indeed.  I tried adding the #define manually to 
/usr/src/lttng-ust-2.3.0/config.h before running make again.  It failed in 
precisely the same way.  This confirms the problem is not with config.h.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
RDDC - Centre de recherches de Valcartier | DRDC - Valcartier Research Centre
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] userspace-rcu on ARMv7 (Beagle Bone Black)

[Thibault, Daniel]

   I've tried deploying userspace-rcu onto a bare, out-of-the-box Beagle Bone 
Black (running Angstrom GNU/Linux v2012.12 (Core edition) on kernel 3.8.13).  
The dependencies seem to be all there (libc6 (2.4 vs. 2.16-r15), automake (1.10 
vs. 1.12.3-r2.1), libtool (2.2 vs. 2.4.2-r5)).

   The bootstrap and configure steps bring no surprises, with minor differences 
with respect to a Ubuntu deployment (BBB has gawk, Ubuntu has mawk; the maximum 
command line length is 32 768 for BBB, 1 572 864 for Ubuntu; BBB is missing mt; 
BBB's gcc -static does not work; where Ubuntu checks for the mfence 
instruction, BBB checks for the dmb instruction).

   The make step, however, seems to go into an infinite loop.  It invokes 
automake-1.12 --foreign, then config/missing --run autoconf, repeat.

   Anyone know why?  And how to fix it?

   (Using userspace-rcu-0.8.0-2)

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] userspace-rcu on ARMv7 (Beagle Bone Black)

[Thibault, Daniel]

   Problem solved.  I should have heeded the warning make first thing:

Make: Warning: File `Makefile.am' has modification time [...] in the future

   This was because the Beagle Bone Black's clock started on January 1st, 2000 
and wasn't set, being off-network.  The imported userspace-rcu files had proper 
timestamps, of course, so make ended up refreshing endlessly to catch up.

   Is there something we could put in the Makefile.am that would tell make to 
treat that particular warning as a fatal error?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] lttng-ust under the hood

[Thibault, Daniel]

-Message d'origine-
De : Gerlando Falauto [mailto:gerlando.fala...@keymile.com] 
Envoyé : 2 juin 2014 11:18

 Thank you very much for your examples and explanations.
 I'm slowly starting to understand.
 I believe with optional linking (whereas your *USERS* need to #define both 
 TRACEPOINT_DEFINE and TRACEPOINT_PROBE_DYNAMIC_LINKAGE), even the dependency 
 to liblttng-ust.so and (consequently) liblttng-ust-tracepoint.so is dropped.
 This means you only need to add -ldl to your application's LDFLAGS, and the 
 two binaries liblttng-ust.so and liblttng-ust-tracepoint.so need not be 
 copied to the target's rootfs.
 Is that right?

   Yes, in the sense that libtp.so need not be present on the 'target rootfs' 
for the instrumented application to run.  But if you want the instrumented 
application to be traced, libtp.so must be present on the target file system 
(so the application can find it).

 However, I get the impression that such a feature is not available for
 tracef() (meaning, if you're using tracef(), there's no way you can 
 optionally link to it -- the above shared objects need to be present on the 
 target's filesystem).
 Is my understanding right? If so, is there are reason for it?

   I can't speak about tracef(): this is a more recent feature whereas I 
feature-froze LTTng at 2.3.0-1 in order to complete the documentation project.  
I will be moving on to 2.4 and 2.5 in the near future, but for now someone else 
will have to act as tracef()'s advocate.  I would presume it works the same way 
as tracepoint(), in the sense that the instrumented application remains 
runnable even when the tracepoint provider shared object can't eb found.

 What I'm looking for is some way to instrument the code without touching the 
 target filesystem unless needed.

 I believe this is probably against the whole idea of tracing (where you want 
 tracing to ALWAYS be available, given its negligible overhead, as per 
 Murphy's Law the moment it'll prove most valuable is when you least expect it 
 to), still...

   Modifying the target file system is unavoidable, I'd think.  The 
applications need to be instrumented (that's one modification), and there must 
be support for tracing on the target: the session daemon and consumer daemon 
must be installed (you can omit installing the LTTng kernel modules if you only 
need to trace user-space) and run, and the instrumented applications' 
tracepoint provider must be present, either in the apps themselves (static 
linking) or as a shared object.  You can at least avoid storing the trace 
itself on the target file system, by exporting the trace data over the wire.

 Thanks a lot!
 Gerlando

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] LTTng 2.5 save/load feature feedback

[Thibault, Daniel]

--
Date: Fri, 30 May 2014 11:54:02 -0400
From: Julien Desfossez jdesfos...@efficios.com

 [...]
 Everything went fine (except for the already known bug of all the contexts 
 information not recorded in the XML file). As expected, the XML file was 
 saved in
 ~/.lttng/sessions/lttngtop.lttng.

 What surprised me was to see this message when later on I started manually a 
 lttng-sessiond as my user (after it had been killed) :
 Error: Failed to load session lttngtop: Tracing the kernel requires a root 
 lttng-sessiond daemon, as well as tracing group membership or root user ID 
 for the lttng client.
 Error: Session load failed: Tracing the kernel requires a root lttng-sessiond 
 daemon, as well as tracing group membership or root user ID for the lttng 
 client.

 I did not expect that the saved sessions would try to auto load when the 
 sessiond was starting. 
 I did not try with system-wide sessions, but that's the same, I don't really 
 expect that all sessions to be automatically loaded on startup.
 I think a sysadmin (or even the lttng installer) could make some tracing 
 profiles available to the users in there so that they can use them when 
 needed.
 Also, the fact that a user sessiond tries to load a session that clearly 
 requires a root sessiond is kind of confusing.

 I can see the value of having auto-loaded sessions, but I think it should be 
 configurable, either directly in the XML (just like to started option) or 
 with sessions saved in a different path (for example ~/.lttng/auto-sessions/).
 Also, I think that our users are never really spawning manually a sessiond, 
 so maybe the lttng load -a is more suited for the auto-loading process.

 So we could maybe add an option to the lttng save command that allows the 
 user to specify if the session should be auto-loaded.
 With that in mind, should the users part of the tracing group allowed to save 
 auto-loading kernel sessions in the system-wide tracing directory, or will 
 they have to ask an admin to manually install their profile ?

 I apologize for not providing this kind of feedback when the RFC was posted 
 here, I just realized these usability details when I actually experimented 
 the feature.

 Julien

   This is a direct consequence of the session concept being user-oriented: the 
sessions belong to users.  But users that belong to the tracing group can run 
lttng in two ways, as you've run into: they can run a private session daemon, 
or talk to the root daemon.

   I would suggest adding a property to the session file that would identify 
the target session daemon.  The session daemons would, upon trying to load the 
sessions, silently reject the inappropriate ones.  The only problem with this 
approach is that sessions targeting either daemon could not bear the same names.

   Alternately, sessions could be stored in two sub-directories of 
~/.lttng/sessions/ depending on the target daemon: say ~/.lttng/sessions/root/ 
and ~/.lttng/sessions/user/.  This would allow homonymous sessions.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [documentation] Drawing: LTTng architecture in relation to the commandline / buffer options

[Thibault, Daniel]

De : Randy Wijnants [mailto:ra...@tty32.org]
Envoyé : 28 mai 2014 07:50

 Thanks for the explaination of the interface between the session and consumer 
 daemon.

 Incorporated all of your suggestions into the graphic.

 Updated version:
 http://tty32.org/Logging%20configuration2.png--ESFSECEV-TY3011
 http://tty32.org/Logging%20configuration2.svg--ESFSECEV-TY3011

 Should i push the SVGs to lttng git repo at this point?

 Randy Wijnants.

   There is one small problem with the diagram as it currently stands : 
lttng-relayd does not intervene on the sender side.  When sending the trace 
data to a remote location, the lttng-consumerd reads from the buffer and sends 
over the wire instead of writing to the local file system.  On the destination 
machine, lttng-relayd receives the data and writes it to the destination 
machine’s local file system.  The first lttng-relayd box of the diagram does 
not exist.

   Finally, you may want to add a control arrow running from Eclipse TMF to the 
session daemon (this is achieved through SSH, as far as I can recall).

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJhttp://www.travelgis.com/map.asp?addr=918V%20QSDJ 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [documentation] Drawing: LTTng architecture in relation to the commandline / buffer options

[Thibault, Daniel]

Envoyé : 28 mai 2014 07:50

 http://tty32.org/Logging%20configuration2.png--ESFSECEV-TY3011
 http://tty32.org/Logging%20configuration2.svg--ESFSECEV-TY3011

   Not sure where the ‘streaming socket’ fits in this picture, though.  
Simplest solution would be to remove it from the diagram (since no other 
sockets are shown anyway).
Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245--ESFSECEV-TY3011---
Fax : (418) 844-4538--ESFSECEV-TY3011---
NAC : 918V QSDJ--ESFSECEV-TY3011 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ--ESFSECEV-TY3011
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/--ESFSECEV-TY3011-
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [documentation] Drawing: LTTng architecture in relation to the commandline / buffer options

[Thibault, Daniel]

De : Randy Wijnants [mailto:ra...@tty32.org]
Envoyé : 27 mai 2014 06:34

 Changed the dashed arrows into dotted arrows.

 Is the arrow running from the lttng session daemon to liblttng-ust valid?
 Does the liblttng-ust always write to the shared memory buffer or only if the 
 session daemon instructs it to (via which interface?)
 And what is the interface used between the session and consumer daemon?

 New version:
 http://tty32.org/Logging%20configuration2.png--ESFSECEV-TY3011

 Randy Wijnants.

   Unless I’m mistaken, when a session daemon disables a channel, for instance, 
it asks liblttng-ust to turn off the immediate value test in the registered 
applications (each tracepoint entry is guarded by an immediate value test which 
is controlled by changing a single byte).  That’s the principle, anyway.  I 
haven’t actually followed this through the tangle of LTTng’s code.
   Rest assured that if liblttng-ust writes to a channel’s buffer, it’s because 
the event was enabled at the time.
   I know the consumer daemon(s) read(s) /run/lttng/lttng-session.pid (or 
$HOME/.lttng/lttng-session.pid) to reach the session daemon.  I think the 
session daemon uses the /run/lttng/ustconsumerd64 (or 
$HOME/.lttng/ustconsumerd64; 32-bit versions may also exist) socket to send 
commands to the consumer daemon(s).
   About the only things the diagram is missing now are:
* the lttng-relayd daemon (which completes the “Network destination / 
streaming” box);
* the add-context command (easily put beside enable-channel and enable-event); 
and
* the buffers-global / buffers-pid / buffers-uid alternative (could be put 
opposite the output TYPE at the Buffer’s top right).
   Change:
* “LTTv” into “LTTV”
* “Eclipse” into “Eclipse TMF”
* “tracefilesize” into “tracefile-size”
* “commandline” into “command line”
Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJhttp://www.travelgis.com/map.asp?addr=918V%20QSDJ 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [documentation] Drawing: LTTng trace session in relation to commandline options

[Thibault, Daniel]

--
Date: Tue, 27 May 2014 13:34:20 +0200
From: Randy Wijnants d...@tty32.org

 In addition to the LTTng architecture diagram, I've drawn a diagram that 
 shows the relation between the command line options and how to configure a 
 trace session.
 I hope it proves to be useful, if you have any suggestions let me know!

 Originally posted on IRC. As suggested by Compudj i've released it under CC 
 license.

 http://tty32.org/Trace%20session.png
 http://tty32.org/Trace%20session.svg

 Randy Wijnants.
--

   Neither the png nor svg versions line up correctly the text and coloured 
boxes with each other.  This may be a local rendering issue.  At least the svg 
version has a proper white background (my png renders with a very dark grey 
background, making it very hard to make out some of the text).  However, the 
svg version is unusable because none of the text is text: everything is 
svg:path with opaque d attributes (this may explain the alignment problems).

   Here are improved (more accurate) expressions for the various command 
syntaxes:

$ lttng create [NAME] [--ctrl-url URL --data-url URL | --output PATH | 
--set-url URL | --no-output] [--snapshot]
   (the ctrl-url etc. options are in pre-emption order)

$ lttng enable-channel (-k | -u) [--session NAME] NAME[,NAME2,...] [--discard | 
--overwrite] [--subbuf-size SIZE] [--num-subbuf NUM] [--switch-timer USEC] 
[--read-timer USEC] \

[--output (mmap | splice)] [--buffers-uid | 
--buffers-pid | --buffers-global] [--tracefile-size SIZE [--tracefile-count 
COUNT]]

$ lttng enable-event (-k | -u) [--session NAME] [--channel NAME] (--all 
[--tracepoint | --syscall] | \
NAME[,NAME2,...] [--tracepoint 
[(--loglevel | --loglevel-only) LOGLEVEL] [--filter 'EXPRESSION'] | (--probe | 
--function) (addr | symbol | symbol+offset)])

$ lttng add-context (-k | -u) [--session NAME] [--channel NAME] (--type TYPE)+

$ lttng list (-k | -u)
   (not the full syntax, but rather the syntax that will get just a list of 
event names)

$ lttng add-context --help
   (the only one that doesn't change!)

   Change Kernelspace specific into Kernel specific.

   Add footnotes:
* --session NAME defaults to the current session
* --channel NAME in the enable-event case defaults to 'channel0', but only if 
the domain is virgin
* --channel NAME in the add-context case defaults to all channels

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] lttng-ust under the hood

[Thibault, Daniel]

 --
 Date: Thu, 22 May 2014 18:21:29 +0200
 From: Gerlando Falauto gerlando.fala...@keymile.com

 I'm still struggling to figure out why, depending on how I compile 
 and link my application, I can get either custom tracepoint providers OR 
 tracef() to work, but not both at the same time.

 Is there any documentation explaining how lttng-ust is roughly supposed to 
 work?
 (i.e. linking trickeries, libraries needed in LD_PRELOAD, 
 _LGPL_SOURCE, tracepoints, probes and so on...)

 Gerlando

 It's all a matter of choice.  Tracepoint providers can be in the app 
 (statically linked in) or dynamically linked to it.  In the latter case, the 
 linking can be mandatory (so the app will fail to launch if it cannot find 
 the tracepoint provider .so) or optional.  With optional linking, failure to 
 find the .so means the app isn't traceable but otherwise runs normally.

Could you elaborate more on this optional linking? Perhaps it's the kind of 
problem I'm running into.

Assume tp.c to consist of just two lines:

--
#define TRACEPOINT_CREATE_PROBES
#include tp.h
--

tp.h is the tracepoint provider header, pretty much boilerplate:

--
#undef TRACEPOINT_PROVIDER
#define TRACEPOINT_PROVIDER sample_component
#undef TRACEPOINT_INCLUDE
#define TRACEPOINT_INCLUDE ./tp.h
#if !defined(_SAMPLE_COMPONENT_PROVIDER_H) || 
defined(TRACEPOINT_HEADER_MULTI_READ)
#define _SAMPLE_COMPONENT_PROVIDER_H
#include lttng/tracepoint.h
#ifdef __cplusplus
extern C {
#endif /* __cplusplus */
TRACEPOINT_EVENT(
...
)
TRACEPOINT_LOGLEVEL(
...
)
#ifdef __cplusplus
}
#endif /* __cplusplus */
#include lttng/tracepoint-event.h
#endif /* _SAMPLE_COMPONENT_PROVIDER_H */
--

   Now for some Makefile fragments.

--
LIBDL = -ldl # On Linux
#LIBDL = -lc # On BSD
LIBUST = -llttng-ust
LDFLAGS += -L/usr/local/lib $(AM_LDFLAGS)
LOCAL_CPPFLAGS += -I. $(AM_CPPFLAGS)
SOFLAGS = -fPIC
SOVERSION_MAJOR = 1
SOVERSION_MINOR = 0

libtp.so: libtp.o
@echo ~~Packaging $@:
$(CC) -shared -Wl,-soname,$@.$(SOVERSION_MAJOR) -Wl,-no-as-needed \
   -o $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR) $(LDFLAGS) $(LIBUST) $
ln -sf $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR) $@.$(SOVERSION_MAJOR)
ln -sf $@.$(SOVERSION_MAJOR) $@

libtp.o: tp.c tp.h
@echo ~~Compiling $@:
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(SOFLAGS) -c -o $@ $
--

The -as-needed linker flag means the libraries mentioned in the command line 
(LIBUST) generate a NEEDED tag in the executable only if actually satisfying an 
otherwise undefined symbol reference. If present, the resulting library won't 
NEED liblttng-ust, which breaks tracing.

Here is how the tracepoint provider (libtp) can be dynamically included as a 
dependency.  The sample application is statically aware of libtp and won't run 
without it (the inclusion of a libtp NEEDED tag requires -no-as-needed -ltp). 
 Besides the recommended LD_PRELOAD technique, you could also use 
#LD_LIBRARY_PATH (which does not work in the 'dynamic' target case, below).  
Note that -L. -ltp, when used, should appear before $(LDFLAGS) $(LIBDL).

--
TP_DEFINE = -D TRACEPOINT_DEFINE

static.o: sample.c tp.h
@echo ~~Compiling $@:
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(TP_DEFINE) -c -o $@ $

static_aware: static.o libtp.so
@echo ~~Linking sample_$@:
$(CC) -Wl,-no-as-needed -o sample_$@ -L. -ltp $ $(LDFLAGS) $(LIBDL)
@echoUse 'LD_PRELOAD=./libtp.so ./sample_$@' to run sample_$@
--

static_aware could also be written with a -Wl,-rpath,'$$ORIGIN' linker call 
(see below).   This would add an RPATH tag to the application which makes it 
look for its dependencies in its starting directory ($ORIGIN). RPATH is, unlike 
RUNPATH, applicable to libraries as well: a library with an RPATH tag will look 
there for its dependencies; failing its own RPATH, it will use its executable's 
RPATH.

--
static_aware: static.o libtp.so
@echo ~~Linking sample_$@:
$(CC) -Wl,-no-as-needed -o sample_$@ -L. -ltp $ $(LDFLAGS) $(LIBDL) \
   -Wl,-rpath,'$$ORIGIN',--enable-new-dtags
--

Here is how the tracepoint provider (libtp) can be dynamically included without 
static awareness.  If not preloaded, the sample application runs but won't 

Re: [lttng-dev] [documentation] Drawing: LTTng architecture in relation to the commandline / buffer options

[Thibault, Daniel]

--
Date: Mon, 26 May 2014 11:27:35 +0200
From: Randy Wijnants ra...@tty32.org

 I've drawn the LTTng architecture in relation to the commandline / buffer 
 options.
 It would be nice if it would be used on the lttng website (if you find it 
 usefull ofcourse).
 I'm using this for a presentation at our company to explain more in-depth 
 lttng configuration details.

 Originally posted on IRC. As suggested by Compudj i've released it under CC 
 license.

 Let me know what you think of it or if you have suggestions / improvements
:)
 I can also provide SVG image, or push it to the repo?

 http://tty32.org/Logging%20configuration2.png

 Randy Wijnants.
--
   SVG, please.  I may end up integrating it into the DocBook documentation.

   The dashed arrows running from userspace to liblttng-ust and the kernel to 
LTTng kernel module(s) don't make sense.  The remaining dashed arrows (all 
running from the session daemon) all represent control flow, which is not what 
happens between userspace/kernel and liblttng-ust/LTTng-kernel-modules.  You 
should use a different convention, such as dotted arrows.

   The enable-channel arrow should be accompanied by an enable-event arrow 
(same functionality, different resolution).

   You could also add a box for the lttng client, which talks to (controls) the 
session daemon.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] lttng-ust under the hood

[Thibault, Daniel]

--
Date: Thu, 22 May 2014 18:21:29 +0200
From: Gerlando Falauto gerlando.fala...@keymile.com

 I'm still struggling to figure out why, depending on how I compile and link 
 my application, I can get either custom tracepoint providers
 OR tracef() to work, but not both at the same time.

 Is there any documentation explaining how lttng-ust is roughly supposed to 
 work?
 (i.e. linking trickeries, libraries needed in LD_PRELOAD, _LGPL_SOURCE, 
 tracepoints, probes and so on...)

 Gerlando

   It's all a matter of choice.  Tracepoint providers can be in the app 
(statically linked in) or dynamically linked to it.  In the latter case, the 
linking can be mandatory (so the app will fail to launch if it cannot find the 
tracepoint provider .so) or optional.  With optional linking, failure to find 
the .so means the app isn't traceable but otherwise runs normally.  LD_PRELOAD 
is generally used to provide the app with the tracepoint provider .so when 
tracing is desired.

   Extensive documentation (in PDF) is currently undergoing editorial review, 
and the plan is to move said documentation to DocBook format so it can be 
included in the LTTng distribution.

  Since tracef() depends on liblttng-ust just like ordinary UST, I'm not sure 
which problem you're running into.  Could you give us a simplified makefile 
that showcases the issue?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [PATCH lttng-tools] Documentation: document tracefile max size discarded event limitation

[Thibault, Daniel]

--
Date: Wed, 21 May 2014 12:10:24 -0400
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com
To: David Goulet dgou...@efficios.com

diff --git a/doc/man/lttng.1 b/doc/man/lttng.1
index 55fbae6..4a1de2c 100644
--- a/src/bin/lttng/commands/enable_channels.c
+++ b/src/bin/lttng/commands/enable_channels.c
@@ -136,6 +136,8 @@ static void usage(FILE *ofp)
fprintf(ofp,   -C, --tracefile-size SIZE\n);
fprintf(ofp,Maximum size of each tracefile 
within a stream (in bytes). 0 means unlimited.\n);
fprintf(ofp,(default: %u)\n, 
DEFAULT_CHANNEL_TRACEFILE_SIZE);
+   fprintf(ofp,Note: traces generated with 
this option may inaccurately report\n);
+   fprintf(ofp,discarded events as per CTF 
1.8.\n);
fprintf(ofp,   -W, --tracefile-count COUNT\n);
fprintf(ofp,Used in conjunction with -C 
option, this will limit the number\n);
fprintf(ofp,of files created to the 
specified count. 0 means unlimited.\n);
--

   as per CTF 1.8 leaves the impression that the misreporting is mandated.  
I suspect this is not what is meant here.  Maybe as of instead of as per?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] clarification on limiting the size of the trace file

[Thibault, Daniel]

--
Date: Mon, 5 May 2014 16:10:06 +

   Your command sets up a single user-space channel named perf which uses a 
 32-part buffer of total size 32*262144=8388608 (8 MiB).
   The trace is itself limited to 32 chunks of size 262144 each.  By default, 
 user-space channels run in discard mode.  So in this case LTTng
 should capture about 8 MiB of events to disc, and a further 8 MiB in memory 
 before giving up altogether.

   When the trace is started the 8 MiB buffer will start filling up, and the 
 consumer daemon will start dumping the events to the trace file.
 Once the trace file saturates at 8 MiB total size, the consumer daemon will 
 stop emptying the buffer.  The buffer will then capture
 another 8 MiB of events.  Once the buffer is full, LTTng will systematically 
 discard new events as they occur.

   It would be an interesting feature if the snapshot command could be used at 
 this point to dump the 8 MiB of otherwise-lost events to another trace file.

   My apologies, I misspoke.  The discard/overwrite setting of the channel is 
independent of the trace file size/count settings, in the sense that it only 
matters when comparing the relative data rates of the trace providers and 
consumers.  In the example above, the on-disc trace file does *not* saturate: 
rather, once all 32 file chunks have been written, the consumer daemon re-uses 
chunk 0, then chunk 1, etc.  The on-disc trace file in effect becomes a 
circular buffer itself.

   It could be an interesting feature to have a separate option, say 
'tracefile-discard', which would have the trace file, when tracefile-size is 
specified, prevent re-use of its files (or chunks if also specified).  This 
could be used to capture a trace of the boot process events, for instance 
(which you can already do using snapshot+discard mode).  If anyone thinks this 
may be of use, please submit a feature request on bugs.lttng.org.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] clarification on limiting the size of the trace file

[Thibault, Daniel]

   We are working with lttng version 2.04.
  This feature may not have been mature with version 2.0.4; I would recommend 
  upgrading to at least 2.3 if not 2.4.
 Envoyé : 7 mai 2014 01:12
 This is what I understood should happen but in the actual run the lttng file 
 fills all the free space in the partition 4GB.
 Mirit Sadon 

   I just ran a test and in both kernel and user-space tracing modes LTTng 2.3 
behaved precisely as expected.  I can only suggest that your problem is 
probably due to LTTng 2.0.4 not handling the instructions correctly.  Upgrading 
is the solution.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [RFC Patch Ust 2/5] Serialize the CTF global structures for ust-comm

[Thibault, Daniel]

--
 Date: Fri, 2 May 2014 09:29:09 + (UTC)
 From: Mathieu Desnoyers mathieu.desnoy...@efficios.com
 To: Geneviève Bastien gbastien+lt...@versatic.net

 Yes, all this is about not repeating global type descriptions over the Unix 
 socket between applications and session daemon.

 The issue here is that with the current approach, we have to repeat possibly 
 very long descriptions of structures, variants, and enums because they need 
 to be bundled after every event description.

 Here is what I would envision instead:

 - We add a global type notifier to the UST notifiers (there is currently 
 only event and channel). Those notifiers are sending the descriptions
   of channels and events as seen from within the application to 
 lttng-sessiond, so it can put it in its ust registry to later generate
   the metadata.
 - Those notifiers can be used to send descriptions of enums, structs, and 
 variants.
 - We'll probably want to have some way of verifying if the global type is 
 exactly the same as global types with the same provider and
   global type names registered previously, thus dealing with different 
 provider .so versions, each containing different versions of the global
   type. We'll have to find out what's the behaviour when this check does not 
 succeed (failure or versioning of the global type within sessiond ?).
   This verification will be needed once per global type, per application 
 process. This verification needs to be done by sending the provider and
   global type name, along with the global type details (to see if it matches).
 - Per global type, per application, we can keep a flag that knows whether the 
 global type description has been successfully sent to the session
   daemon for each session.

   I'd strongly advise to go the versioning way rather than the failure way 
(although failure is easier to implement initially).  The verification needs to 
be done more often than once per global type, per application process: one 
use case is a process that dynamically loads (dlopen) an instrumented .so, 
generates events with it for a while, then unloads it (dlclose) and loads 
another .so that happens to include a provider with the same signature but 
different event payloads.  The process may or may not wholly unregister from 
and re-register with the session manager, depending on whether or not it has 
other providers loaded.

   See the closely related bugs #561, #698, #720.

   If the bandwidth used in sending lengthy type descriptions for mere 
verification is a concern, maybe the conversation between the app tracepoint 
provider and session manager could start by sending an MD5 or SHA hash of the 
type description.  Only when those mismatch would the full type description 
need to be sent.

   Also note that event type verification can be lazy (or delayed) and 
occur only when the event type in question is actually enabled or emitted.  
There isn't much point to updating the trace metadata with changing event types 
if the events in question are not enabled (at the channel or event level).  On 
the other hand, sending a filter specification to a provider pretty much 
requires event type verification, if only to warn the user that the filter he 
specified for the event won't be understood by the provider.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] lttng git repositories and Eclipse

[Thibault, Daniel]

   Using a fresh Eclipse C/C++ environment (Kepler 4.3.2), what's the best way 
to load the LTTng git source tree?  Cloning the git.lttng.org lttng-ust master 
branch (for example) is easy, my problem is in getting the Autotools to kick in 
properly.  Eclipse's array of options is somewhat overwhelming; as a 
consequence I've managed to build userspace-rcu, but I didn't take notes and I 
can't seem to reproduce the method with lttng-ust.  Frustrating.

File: Import...
[Import]
Git  Projects from Git
(Next)

[Import Projects from Git: Select Repository Source]
Clone URI
(Next)

[Import Projects from Git: Source Git Repository]
URI: http://git.lttng.org/lttng-ust.git
(Host: git.lttng.org)
(Repository Path: /lttng-ust.git)
(Protocol: http)
(Next)

[Import Projects from Git: Branch Selection]
(Deselect All) (master)
(Next)

[Import Projects from Git: Local Destination]
Directory: /home/username/git/git.lttng.org/lttng-ust
(Initial branch: master)
Clone submodules
(Remote name: origin)

[Cloning from http://git.lttng.org/lttng-ust.git: Select a wizard to use for 
importing projects]

This is where I need advice.  The three options are:

Import existing projects
Import as general project
Use the New Project wizard

   Clearly the first is not applicable since the source trees are not Eclipse 
projects (neither should they be).

   If I Use the New Project wizard, the two pertinent choices seem to be:

C/C++  C Project
and
C/C++  Makefile Project with Existing Code

   In the first case, Project type: GNU Autotools only allows Empty project 
which is no good.

   In the second case, I must browse to the git clone directory.  I end up with 
an inert project, but if I then go to its Properties: Builders, there is no way 
to add GNU Autotools.

   If I Import as general project, I can then invoke File: New: Convert to a 
C/C++ Autotools Project.  This *almost* works, with the console showing 
configure attempting to run and failing because bootstrap did not run 
(Invoking autoreconf in build directory: 
/home/daniel/git/git.lttng.org/lttng-ust/  |  sh -c autoreconf -i  |  
aclocal: couldn't open directory `config': No such file).  I can shell out to 
the directory, run bootstrap, then refresh the Eclipse project and pick 
Reconfigure project from the contextual menu.  I can't help but hope there's 
an easier, better way?

   Help?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] lttng git repositories and Eclipse

[Thibault, Daniel]

Date: Wed, 30 Apr 2014 11:57:34 -0400
From: Marc-André Laperle marc-andre.lape...@ericsson.com

 On 14-04-30 11:48 AM, Thibault, Daniel wrote:
  File: Import...
  [Import]
  Git  Projects from Git
  (Next)
  [...]
  [Cloning from http://git.lttng.org/lttng-ust.git: Select a wizard to use 
  for importing projects]
  Use the New Project wizard
 
  C/C++  C Project
 
Project type: GNU Autotools only allows Empty project which is no good.
 [...]

 Try it this way it should work. Change the location to point to your 
 lttng-ust folder. Basically, every .configure folder should map to a
 different CDT project. Empty project in this case means that it just 
 doesn't create source files for you. Makefile Project with Existing
 Code does pretty much the same thing as a new project with Makefile  Empty 
 project but there's no Autotools equivalent.

 Marc-André

   Thanks, that works!

   What's odd is that the console, in this case, shows it starts the 
configuration with 'sh -c autoreconf -i', just like it did when I converted 
the imported general project to a C/C++ Autotools Project.  Why does it succeed 
in running bootstrap when the other fails?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] Problem in userspace-rcu cds_hlist_del_rcu.c caused by #define cds_hlist_for_each_entry_safe_2

[Thibault, Daniel]

   When compiling userspace-rcu (commit 81dd913), I get a pair of warnings for 
/userspace-rcu/doc/examples/hlist/cds_hlist_del_rcu.c at the 
cds_hlist_for_each_entry_safe_2 call:

cds_hlist_for_each_entry_safe_2(node, n, mylist, node) {
if (node-value  0) {
cds_hlist_del_rcu(node-node);
/*
 * We can only reclaim memory after a grace
 * period has passed after cds_hlist_del_rcu().
 */
call_rcu(node-rcu_head, free_node_rcu);
}
}

   The warnings are:
attention: assignment makes pointer from integer without a cast
attention: left operand of comma operator has no effect

   The #define comes from userspace-rcu/urcu/hlist.h (here re-arranged a bit):

#define cds_hlist_for_each_entry_safe_2(entry, e, head, member) \
for (entry = ((head)-next == NULL ? NULL : 
cds_hlist_entry((head)-next, __typeof__(*entry), member)); \
(entry != NULL)  \
(e = (entry-member.next == NULL ? NULL : 
cds_hlist_entry(entry-member.next, __typeof__(*entry), member), 1)); \
entry = e)

   The cds_hlist_del_rcu.c occurrence is the only use of 
cds_hlist_for_each_entry_safe_2 and the problem seems to me to lie in this bit:

(e = (entry-member.next == NULL ? NULL : cds_hlist_entry(entry-member.next, 
__typeof__(*entry), member), 1))

   Because the comma operator has the lowest precedence of all operators, the 
statement is equivalent to:

(e = ((entry-member.next == NULL ? NULL : cds_hlist_entry(entry-member.next, 
__typeof__(*entry), member)), 1)) 

   Which is in turn the same as:

(e = 1)

   Now, if the macro is using the comma to make the second part of the  test 
succeed regardless of the value fetched for e, then it should have been written:

#define cds_hlist_for_each_entry_safe_2(entry, e, head, member) \
for (entry = ((head)-next == NULL ? NULL : 
cds_hlist_entry((head)-next, __typeof__(*entry), member)); \
(entry != NULL)  \
((e = (entry-member.next == NULL ? NULL : 
cds_hlist_entry(entry-member.next, __typeof__(*entry), member))), 1); \
entry = e)

   Which does compile without the warnings.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] memory usage depending on number and size of subbuffers

[Thibault, Daniel]

--
 Date: Wed, 16 Apr 2014 18:22:42 +0200
 From: S?bastien Barth?l?my barthel...@crans.org

 LTTng uses more memory than I expected. On the simple experiment below one 
 can see that the cached memory increases by

 subbuf_size*num_cpu*(num_subbuf+1)

 That's not a big deal, but I did not expect the +1.

 Does somebody know where it comes from?

 Date: Wed, 16 Apr 2014 17:32:39 + (UTC)
 From: Mathieu Desnoyers mathieu.desnoy...@efficios.com
 It is the extra sub-buffer needed for reading a sub-buffer while the 
 other sub-buffers are written into. It's needed for snapshotting 
 data while tracing is active. 

 Mathieu 

   If I'm not mistaken, the passing sub-buffer is used in overwrite mode (as 
opposed to discard mode), not especially for snapshot mode.  It is in fact 
possible to run in snapshot+discard mode, although that may not be very useful 
in most use cases.  Can you confirm, Mathieu?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [PATCH lttng-tools] utils: Rework utils_parse_size_suffix

[Thibault, Daniel]

--
Date: Thu, 10 Apr 2014 11:30:19 -0400
From: Simon Marchi simon.mar...@polymtl.ca

+++ b/src/common/utils.c
@@ -650,42 +649,10 @@ error:
[...]
  * The suffix multiply the integer by:

   Should be The suffixes multiply the integer by:

@@ -693,83 +660,94 @@ static void regex_print_error(int errcode, regex_t *regex)
[...]
+   /* strtoull will accept a negative number, but we don't want to. */
+   if (strchr(str, '-') != NULL) {
+   DBG(utils_parse_size_suffix: invalid size string, should not 
contain '-'.);
ret = -1;
+   goto end;
}

   Should be [...] should not begin with '-' [...] (although it is true 
 the size string should not *contain*, the test is only for *begins with*)

[...]
+   if (num_end == str) {
+   /* strtoull parsed nothing, not good. */
+   DBG(utils_parse_size_suffix: strtoull had nothing good to 
parse.\n);
+   ret = -1;
+   goto end;
+   }

   utils_parse_size_suffix: zero-length size string. would be clearer.  
 Also note that the preceding DBG strings did not end with '\n'.

+   /* Check if a prefix is present. */

   That should be suffix.

[...]
+   default:
+   DBG(utils_parse_size_suffix: invalid suffix.\n);

   Another DBG string with a superfluous trailing '\n'.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] [PATCH lttng-tools] utils: Rework utils_parse_size_suffix

[Thibault, Daniel]

--
Date: Thu, 10 Apr 2014 14:43:38 -0400
From: Simon Marchi simon.mar...@polymtl.ca

   Should be [...] should not begin with '-' [...] (although it is 
 true the size string should not *contain*, the test is only for 
 *begins with*)

 I meant for it to search in the whole string, and that is what I think strchr 
 does.

Oops, my bad.

 [...]
 +   if (num_end == str) {
 +   /* strtoull parsed nothing, not good. */
 +   DBG(utils_parse_size_suffix: strtoull had nothing good to 
 parse.\n);
 +   ret = -1;
 +   goto end;
 +   }

   utils_parse_size_suffix: zero-length size string. would be clearer.  
 Also note that the preceding DBG strings did not end with '\n'.

 This test indeed will catch zero-length strings. However, if you pass 
 hello, or k, strtoull will just parse 0 characters and return the value 
 0. This test is for these cases as well, which are not zero-length strings. I 
 agree that it's not very clear, but I have nothing better...

How about  utils_parse_size_suffix: size string does not begin with a number.?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] instrumenting shared library

[Thibault, Daniel]

   You need to define your concept of operations carefully.

   An instrumented application can include its tracepoint provider in several 
ways.

   One is static inclusion: the application will always be traceable, but any 
change to the tracepoints requires a recompilation of the app, plus the 
tracepoint events it produces should not be shared with any other application 
(I say 'should' because they can, but it's a bad idea to do so).

   Another is dynamic inclusion with static awareness: the application will 
always be traceable, but will refuse to run if does not find the tracepoint 
provider library (typically provided by LD_PRELOAD). The tracepoint events can 
be shared with other applications.

   The third is dynamic inclusion without static awareness: this operates as 
the previous, except that when the app does not find the tracepoint provider it 
runs normally but is not traceable. Turning off traceability in this way does 
give you a very small gain in performance.

   The last is fully dynamic inclusion: the app is responsible for its own 
traceability because it loads and unloads its tracepoint provider itself (using 
dlopen and dlclose). This is more intrusive as the app's code needs to include 
this aspect, possibly reflected in its user interface (by a menu item, for 
instance). On the good side it does mean you get the slight performance gain on 
demand.

   If the very slight loss of performance due to tracing doesn't bother you, 
your best bet is probably dynamic inclusion without static awareness (third 
option). LTTng can then be configured to capture your app's traces using an 
on-disc circular buffer (see the tracefile-size and tracefile-count options of 
the enable-channel command). When your app misbehaves, you suspend it, suspend 
tracing (lttng stop), and copy the trace to a working directory. You can then 
babeltrace it or use the Eclipse LTTng views to analyse the trace. This works 
even better if your app is run multiple times, because then LTTng will capture 
each running separately (see the buffers-pid and buffers-uid options of the 
enable-channel command). You only need to remember to flush the older traces 
once you've decided you don't need them anymore.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJhttp://www.travelgis.com/map.asp?addr=918V%20QSDJ 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] lttng-ust cross compile broken for demo-tracef

[Thibault, Daniel]

--
 Date: Mon, 7 Apr 2014 13:43:21 +0200
 From: Jan Glauber jan.glau...@gmail.com

 I get a compile error with current git head of lttng-ust if I cross-compile 
 (bitbake):

 | make[4]: Entering directory 
 `/home/jang/temp/p4/JGlauber_hal_share/poky/build/tmp/work/armv7ahf-vfp-neon-elina-linux-gnueabi/lttng-ust-2.4-r0/git/doc/examples/demo-tracef'
 | arm-linux-gnueabihf-gcc  -march=armv7-a -mthumb-interwork 
 -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 \
 |
 --sysroot=/home/jang/temp/p4/JGlauber_hal_share/poky/build/tmp/sysroots/omap5 
 -L/home/jang/te \
 |-o demo-tracef demo-tracef.o -ldl -llttng-ust
 | demo-tracef.o: file not recognized: File format not recognized
 | collect2: error: ld returned 1 exit status
 | make[4]: *** [demo-tracef] Error 1

 Looks like the demo-tracef Makefile sets CC hard to gcc. But if I fix this I 
 get more
 errors which I don't undertand. Am I the only one running into this?

 Harman Becker Automotive GmbH
 System Profiling  Optimizing Team

   The  demo-tracef.o: file not recognized: File format not recognized is a 
dead giveaway that you are in a mixed-bitness context.  The linker is in 64-bit 
mode while demo-tracef.o was compiled in 32-bit mode, or vice-versa.  Or it 
could be byte sex.  Clearly, the linker call is not using the same config that 
was used to create demo-tracef.o.  (My apologies if this seems obvious to you; 
I'm not familiar with bitbake)

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] instrumenting shared library

[Thibault, Daniel]

De : Anand Neeli [mailto:anand.ne...@gmail.com]
Envoyé : 7 avril 2014 10:37

 - It doesn't matter if the tracepoints are static or dynamically loaded with 
 the app. Once there is a change in tracepoints the app should be reloaded 
 (even though not compiled). Even though the tracepoints can be shared, but 
 changing tracepoints we would need to restart all the app's which share the 
 tracepoints.
(Just trying to make a statement on pros and cons here)

   Not quite true.  If the tracepoints are statically included in the app, then 
the app must be recompiled and relinked whenever the tracepoints change.  
Example:

static: static.o tp.o
@echo ~~Linking sample_$@:
$(CC) -o sample_$@ $^ $(LDFLAGS) $(LIBDL) $(LIBUST)
@echoUse './sample_$@' to run sample_$@

static.o: sample.c tp.h
@echo ~~Compiling $@:
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(TP_DEFINE) -c -o $@ $

tp.o: tp.c tp.h
@echo ~~Compiling $@:
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) -c -o $@ $

   Every time you change tp.h, you must recompile tp.o and static.o and relink 
both into a new sample_static executable image.  If you keep the tracepoint() 
signatures unchanged, then you may get away with not recompiling static.o-but 
you must still relink.

   At the other extreme, if the app explicitly loads the tracepoint provider 
using dlopen, then one could conceivably send a message to all apps to dlclose 
the tracepoint provider shared object and dlopen a replacement one (if such an 
API has been programmed in).  The apps wouldn't need to stop running at all.  
Of course this supposes the tracepoint() signatures do not change.  (To avoid 
confusing babeltrace, the traces must be collected using the buffers-pid 
channel option and the changeover must not occur within the same one-second 
time window)

 - * Does static or dynamic inclusion make difference(in terms of performance) 
 if someone always want to run in tracing mode??

   The difference will be slight: using a dynamic link, the linker must do a 
little extra work when loading the tracepoint provider shared object along with 
the application's binary image, just because it needs to find it elsewhere. So 
you can expect app startup to be a little longer the first time. If the app is 
using a tracepoint provider shared object which happens to be already used by 
other running apps, the startup time actually becomes shorter because the 
tracepoint provider shared object is already in memory.

   Once the app is running, there should be no difference at all in performance.

 Now let me put some light on how someone would like to use lttngin huge 
 codebases. (this is my personal opinion)
 - Normally tracepoints are made per component/daemon. And not shared across 
 daemons/components.
 - Tracing should always be running. It should never be switched off. (unless 
 the application is not mission critical)
 - I'm planning to always run memory(snapshot) tracing with some fixed size 
 buffer, which can capture last n-events or n-bytes
 - Above memory tracing users can create another tracing session and dump 
 traces to files if needed.(with their own filters and context in enable-event)

   Sounds like a plan!

 Thanks again for spending your time on these queries.
 -Anand Neeli
Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ--ESFSECEV-TY3011 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ--ESFSECEV-TY3011
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/--ESFSECEV-TY3011-
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] tracepoint sys_enter and sys_exit

[Thibault, Daniel]

--
Date: Fri, 04 Apr 2014 08:26:52 -0400
From: Francis Giraldeau francis.girald...@gmail.com
To: zhenyu.ren zhenyu@aliyun.com

  But where are these two tracepoints (hits) in kernel source code?

 If I remember correctly, for x86_64, the file is arch/x86/kernel/entry_64.S 
 and search for syscall_trace_enter.

 Francis

   Syscall_trace_enter appears in a handful of .S files (assembly code) in the 
arch hierarchy.  Also ptrace.c and thread_info.h.  If thread info includes the 
TIF_SYSCALL_TRACEPOINT flag, in the x86 case this invokes the tracepoint 
trace_sys_enter (registered and unregistered by kernel/trace/trace_syscalls.c). 
 The tracepoint provider is the lttng-tracer.ko kernel module.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] instrumenting shared library

[Thibault, Daniel]

De : Anand Neeli [mailto:anand.ne...@gmail.com]
Envoyé : 4 avril 2014 16:17

What i'm looking at it is: adding lttng infra in our code base. I'm looking for 
a solution where most of the lttng build and launch parts are abstracted to the 
end app/library developer.
That is the reason why i'm not in favor of having LD_PRELOAD while launching an 
app. This would need the app developer to check if included libraries has 
tracing support and add .so appropriately to LD_PRELOAD (which needs more 
education to developer on lttng and included libraries)
If we can launch app(with or without instrumented library) normally and limit 
the complexity of linking to makefile it will be great.

Please keep me posted if you have any more thoughts on this.
Also, can you please send me the users guide.

Anand Neeli

   The idea behind using LD_PRELOAD is to have tracing switchable on and off 
without needing to recompile or relink the application.  If you make the app 
statically aware of the tracepoint providers, it won't run (won't load) without 
them.  Of course, if you're comfortable with that, it's okay.
   Another approach is to have tracing controlled by an app option.  This 
requires the app to explicitly load and unload the tracepoint provider using 
dlopen() and dlclose().
   Things are also a little different if all you're instrumenting are the 
libraries the apps are using.  You might be able to get away with using the 
rpath tag and then just moving the tracepoint provider in and out of scope (by 
copying or renaming the tracepoint provider shared object).  This would be a 
rather kludgy global setting (unless the directory where the libraries lie is 
user-specific) and would also not work to turn off tracing while the libraries 
are in use (because the tracepoint provider would refuse to be unloaded).
   I'll send the PDFs separately.
Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ 
http://www.travelgis.com/map.asp?addr=918V%20QSDJ--ESFSECEV-TY3011---
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/--ESFSECEV-TY3011

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

Re: [lttng-dev] instrumenting shared library

[Thibault, Daniel]

--
Date: Thu, 3 Apr 2014 16:55:38 +0530
From: Anand Neeli anand.ne...@gmail.com
To: lttng-dev@lists.lttng.org lttng-dev@lists.lttng.org

 I have a library which is instrumented and tracepoints are added. And I
 have 2 binary's (or daemons) which try to include this library. (one binary
 has instrumented code with tracepoints and other binary doesn't use
 tracing)

 I found that i need to instrument the daemon which includes the
 instrumented library for the code to compile.

 Can't I have a daemon (without tracing functionality) which can include an
 instrumented library (i don't want to use tracing functionality in this
 case)

 I'm only able to build if both library and daemon which includes it are
 instrumented.

 Can anyone please give me more details on how to do this?
 This is useful for huge code bases where you can selectively add tracing
 support to few libraries or daemons.

 Anand Neeli

   It can be done.  An uninstrumented app can rely on an instrumented shared 
object; whether the latter produces lttng events then depends on whether or not 
the tracepoint provider shared object is loaded when the app is invoked (using 
LD_PRELOAD).

   Here is sample_neeli.c:
#
#include stdio.h //For printf
#include unistd.h

#include cobject.h
int main(int argc, char **argv)
{
int i = 0;
char themessage[20]; //Can hold up to Hello World 999\0

fprintf(stderr, sample_neeli starting\n);
for (i = 0; i  1; i++) {
//We either prepare themessage in this module, or rely on an
//external shared object
cobject_message(themessage, i);
usleep(1);
}
fprintf(stderr, sample_neeli done\n);
return 0;
}
#
cobject.c:
#
#include stdio.h //For printf
#include unistd.h

#include tp.h

void cobject_message(char *themessage, int i)
{
tracepoint(sample_component, event, cobject_message);
sprintf(themessage, CObject %u, i);
}
#
cobject.h:
#
extern void cobject_message(char *themessage, int i);
#
The tracepoint provider code should be easy to guess.

The relevant Makefile fragments:
#
CC = gcc
LIBDL = -ldl # On Linux
#LIBDL = -lc # On BSD
LOCAL_CPPFLAGS += -I. $(AM_CPPFLAGS)
LDFLAGS += -L/usr/local/lib $(AM_LDFLAGS)
SOFLAGS = -fPIC
TP_DEFINE = -D TRACEPOINT_DEFINE
TP_DEFINE_DYNAMIC = $(TP_DEFINE) -D TRACEPOINT_PROBE_DYNAMIC_LINKAGE
SOVERSION_MAJOR = 1
SOVERSION_MINOR = 0

libcobject.so: libcobject.o
@echo ~~Packaging $@:
$(CC) -shared -Wl,-soname,$@.$(SOVERSION_MAJOR) -Wl,-no-as-needed \
   -o $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR) $^
ln -sf $@.$(SOVERSION_MAJOR).$(SOVERSION_MINOR) $@.$(SOVERSION_MAJOR)
ln -sf $@.$(SOVERSION_MAJOR) $@

libcobject.o: cobject.c cobject.h tp.h
@echo ~~Compiling $@:
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(SOFLAGS) $(TP_DEFINE_DYNAMIC) \
   -c -o $@ $

neeli_dynamic_lib:: neeli_dynamic_lib.o
@echo ~~Linking sample_$@:
$(CC) -Wl,-no-as-needed -o $@ -L. -lcobject $^ $(LDFLAGS) \
   $(LIBDL) -Wl,-rpath,'$$ORIGIN',--enable-new-dtags
@echoUse '[LD_PRELOAD=./libtp.so] ./$@' to run $@

neeli_dynamic_lib.o: sample_neeli.c cobject.h
@echo ~~Compiling $@:
$(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) -c -o $@ $
#

   Running './neeli_dynamic_lib' yields no events.  Running 
'LD_PRELOAD=./libtp.so ./neeli_dynamic_lib' yields the libcobject.so events.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Minor documentation issue with 2.4.0

[Thibault, Daniel]

--
Date: Wed, 2 Apr 2014 12:23:42 +0300
From: Amit Margalit am...@il.ibm.com

 I ran a command that included an error, and noticed that 'lttng' mentions 
 -j in --buffers-pid and --buffers-uid, but nowhere else:

 usage: lttng enable-channel NAME[,NAME2,...] (-u | -k) [OPTIONS]

 Options:
 [...]
 You can see these 2 lines:

  --buffers-uidUse per UID buffer (-u/-j only)
  --buffers-pidUse per PID buffer (-u/-j only)

 But -j is not explained above.

 Amit Margalit

   Obviously the 2.4 man pages have yet to be fully updated.  -j is the --jul 
(java.util.logging) domain.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] Yet another toxic comment

[Thibault, Daniel]

   lttng-tools/src/bin/lttng-sessiond/main.c, lines 163-169:

/*
 * UST registration command queue. This queue is tied with a futex and uses a N
 * wakers / 1 waiter implemented and detailed in futex.c/.h
 *
 * The thread_manage_apps and thread_dispatch_ust_registration interact with
 * this queue and the wait/wake scheme.
 */

   The fifth line should actually read:

* The thread_registration_apps and thread_dispatch_ust_registration interact 
with

   thread_manage_apps occurs further down the line: it watches the registered 
apps' cmd sockets and triggers unregistration when they close.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] lttng-health-check

[Thibault, Daniel]

LTTNG_HEALTH_APP_MANAGE:
The lttng-health-check function will report the health of the application 
command socket manager subsystem.  This session daemon thread 
(thread_manage_apps) watches the application command sockets; their closure 
indicates application shutdown (more accurately, shutdown of the application's 
tracepoint provider) and triggers unregistration.

Would it be correct to say that if this component malfunctions, closure of 
application trace files (if tracing in per-process ID mode) will be delayed 
until the session is destroyed, but that there won't be any other truly 
deleterious consequences?  It seems unlikely any events will be lost (the 
consumer will commit the buffer contents normally), and this thread failure 
would not hamper tracing of other applications nor client-controlled enabling 
and disabling of events.  The lttng list of event sources would include ghosts 
(dead-and-gone apps).  Could lttng hang if the client tried to toggle the 
enabling of events published by the ghosts?

I guess my point is that, of all the possible health failures, this seems the 
least catastrophic one.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Trace rotation across sessions

[Thibault, Daniel]

--
Date: Tue, 18 Mar 2014 10:19:47 -0400
From: Jérémie Galarneau jeremie.galarn...@efficios.com
To: Amit Margalit am...@il.ibm.com
Cc: lttng-dev lttng-dev@lists.lttng.org

 On Tue, Mar 18, 2014 at 4:52 AM, Amit Margalit am...@il.ibm.com wrote:
  Our system has a running session that stays on continuously.

  Occasionally, our customer will upgrade the software, leading to a 
  reboot, which in turn means we will have a new session.
 
  Is there any way to make LTTng aware of the total size of all sessions 
  (current and past) and simply rotate files to keep the entire set of 
  traces under a size limit?

 The only way I can see this working is by recreating the same session 
 configuration
 (with the same output destination) and using lttng enable-channel's -C 
 (tracefile-size) 
 and -W (tracefile-count) options to define an upper bound on each trace's 
 size.

 Is this what you are looking for?

 J?r?mie Galarneau
 EfficiOS Inc.

   Wouldn't that just overwrite the destination trace files?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] session create failed

[Thibault, Daniel]

--
Date: Wed, 19 Mar 2014 01:19:52 +0800
From: Lingyu Zhu lynus...@gmail.com
To: Jonathan Rajotte jonathan.r.jul...@gmail.com

 Thanks for point that out. But My point is creating session would fail as
 root, only after I  failed enable kernel event as normal user.

   Your session creation remains successful.  You just can't do kernel tracing 
from it.  You could have gone on to enable user-space events, etc.

   The later JUL problem is because you did not 'kill' the local session daemon 
the first lttng command spawned.

   In a nutshell, use 'lttng command' for local user-space tracing, 'sudo -H 
lttng command' for kernel and multiple user-space tracing.  Alternately, join 
the 'tracing' group (log off and back on for the change to take), then use 
'lttng command' for all tracing -but make sure the root daemon is the only 
lttng session daemon running.

   As late as lttng 2.3, the lttng -g option does not work.  Has it been fixed?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Event redefinition/re-enablement

[Thibault, Daniel]

--
Date: Sun, 16 Mar 2014 00:41:28 -0700
From: Ruslan Uvashev ruslan.uvas...@gmail.com

 It seems that event once enabled for a channel cannot be reassigned to 
 another channel.
 If events are immutable will Feature #445 (https://bugs.lttng.org/issues/445)
  account such situation? Or do we need to update man saying that events
 cannot be redefined?

 Command output below.

 $ sudo lttng create tst1
 Session tst1 created.
 Traces will be written in /home/rusty/lttng-traces/tst1-20140315-173020
 $ sudo lttng enable-event writeback_nothread -k
 Kernel event writeback_nothread created in channel channel0
 $ sudo lttng enable-channel ch1 -k
 Kernel channel ch1 enabled for session tst1
[...]
 $ sudo lttng disable-event writeback_nothread -k -c channel0
 Kernel event writeback_nothread disabled in channel channel0 for session tst1
 $ sudo lttng enable-event writeback_nothread -k -c ch1
 Error: Event writeback_nothread: Enable kernel event failed (channel ch1, 
 session tst1)
 Warning: Some command(s) went wrong

   That is a known feature/limitation of LTTng: kernel events can only be 
assigned once (within a session).  User-space events can be assigned to 
multiple channels.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

[lttng-dev] Toxic comments in lttng-sessiond main.c

[Thibault, Daniel]

(for version 2.3)
/usr/src/lttng-tools/src/bin/lttng-sessiond/main.c (3613..3648):

static void *thread_manage_clients(void *data)
{
[...]
DBG([thread] Manage client started);
[...]
ret = lttcomm_listen_unix_sock(client_sock);
[...]
/* Add the application registration socket */
ret = lttng_poll_add(events, client_sock, LPOLLIN | LPOLLPRI);

   Shouldn't that last comment read /* Add the client socket */?

   A little later, lines 3700..3701:

/* Event on the registration socket */
if (pollfd == client_sock) {

   Shouldn't that comment read /* Event on the client socket */?

   Similar copy-and-paste errors appear in one other thread routine: 
thread_manage_health (lines 3453 and 3489).  The others (including the two 
exiled to ust-thread.c and ht-cleanup.c) appear OK.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Working on some bugs

[Thibault, Daniel]

--
Date: Mon, 10 Mar 2014 23:00:36 -0700
From: Sandeep K Chaudhary babbusandy2...@gmail.com

 I want to submit patches for some bugs before making my GSoC application.

 http://bugs.lttng.org/issues/621
 http://bugs.lttng.org/issues/282
 http://bugs.lttng.org/issues/204
 http://bugs.lttng.org/issues/682

http://bugs.lttng.org/issues/633 would also be an easy one to do.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] Can tracepoint be listed before app registered?

[Thibault, Daniel]

--
Date: Wed, 12 Mar 2014 09:56:00 +0800

 The use case is as such a scenario:
 The target app has defined many events and  the user don't want to go over 
 the source code to recall them. Instead, after creating a new session,
 user issue a hypothetical subcommand 'load_probe' which gather the 
 information from the probe library.And since then, user is able to list all
 available events yet before any app is launched.

 Mathieu 's idea  implementing a ELF parser to provide early event-listing 
 feature is a  good proposal. However, do you think the quantity of work
 is plenty enough to be a GSoC proposal?  I asked that because I saw some idea 
 was turned down due to 'not complex enough' in some IRC channel.

 Lingyu

   I would see this as a natural extension of the list command.  Something like 
'lttng list -u --application=/path/app'.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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

Re: [lttng-dev] lttng trace format

[Thibault, Daniel]

 Date: Thu, 20 Feb 2014 21:15:42 -0500
 From: Jessica Foest jessica.fo...@gmail.com

 is there a document that explain the meaning of fields displayed in the 
 traces generated by babeltrace ?

 an example :

 [19:52:06.617756425] *(+0.01667)* workstation sys_splice: { cpu_id = 3
}, { perf_branches = 418157709, perf_branch_instructions = 418156946,
perf_cache_misses = 6682769, perf_cache_references = 50147680,
perf_instructions = 3049323811, vppid = 587, ppid = 587, vtid = 3502, tid =
3502, vpid = 3499, nice = 0, prio = 20, procname = lttng-consumerd, pid =
3499 }, { fd_in = 10, off_in = 0x0, fd_out = 26, off_out = 0x0, len =
65536, flags = 5 }

 the field mentioned in blue , is it the execution time of sys_splice ?

 if yes , what's the necessity of sys_exit ?

   Nothing in blue in the digest version of your post, sadly.  If you mean the 
*(+0.01667)* field, that's just the time elapsed since the previous event.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection  
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber 
Security (MCCS)
R  D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence RD 
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ http://www.travelgis.com/map.asp?addr=918V%20QSDJ
Gouvernement du Canada | Government of Canada
http://www.valcartier.drdc-rddc.gc.ca/

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