-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, C
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
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+%27L
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 ba
--
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.
>
> Unf
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-
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 so
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 tha
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
-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
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
> 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 cauti
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
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 o
--
Date: Tue, 20 Oct 2015 14:28:31 +
From: "Thibault, Daniel"
--
> lttng-modules-2.7.0-stable won't compile under CentOS 7.0. Det
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
--
Date: Thu, 10 Sep 2015 16:07:47 -0400
From: Jonathan Rajotte
---
diff --git a/tests/utils/utils.sh b/tests/utils/utils.sh
@@ -952,6 +952,44 @@ function lttng_untrack_fail()
+function add_context_lttng()
[...]
+ if [[ $expected_to_fail -eq "1" ]]; then
+
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 J
--
Date: Tue, 17 Mar 2015 08:49:59 +0100
From: "Wolfgang Rostek"
> 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),
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
--
Date: Tue, 27 Jan 2015 12:59:09 +0530
From: Divya Vyas
> Is there any option where I can list out the function which I can give in
> dynamic probes?
>
> Thanks, Divya
--
> 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
> htt
>> 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 provide
--
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
--
Date: Tue, 25 Nov 2014 14:04:04 -0500
From: David Goulet
> 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
--
Date: Fri, 21 Nov 2014 15:28:30 +0400
From: Eugene Ivanov
>>Normally you use TRACEPOINT_EVENT_CLASS and _INSTANCE within the same
>> provider, but you could theoretically have varying instances rely on
>> different provide
> Date: Wed, 19 Nov 2014 15:35:01 +0400
> From: Eugene Ivanov
>
> 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
--
Date: Wed, 12 Nov 2014 23:26:41 +0800
From: J Lin
> 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.
> Date: Mon, 10 Nov 2014 13:02:58 -0500
> From: J?r?mie Galarneau
> To: Anand Neeli
>
> > 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
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)
* libp
-Message d'origine-
Envoyé : 20 octobre 2014 16:08
Question: why is it required to give the the arguments to
TRACEPOINT_EVENT_INSTANCE since all tracepoints from the same
class use the same arguments and same field layout ?
-Fin du message d'origine-
Simply put, the arguments
-Message d'origine-
Envoyé : 20 octobre 2014 11:51
> Thanks for testing.
>
> I will use these.
>
> Can I add "Suggested-by: Daniel Thibault "
> in our open source BIOSAL git log ?
Absolutely!
I also take cash, money orders, cheques and payment in kind. :-)
Daniel U. Thibault
Pr
-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 !
--
Date: Fri, 17 Oct 2014 21:39:21 +
From: "Boisvert, Sebastien"
> 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 fie
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_e
> 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 ar
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
The BeagleBone Black rev. C boards come with Debian Wheezy installed (kernel
3.8.13-bone47, distro 'Debian GNU/Linux 7.4 (wheezy)'). The linux-headers are
not supplied, but I found them at
http://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone47/linux-headers-3.8.13-bone47_1.0wheezy_armhf.deb.
Co
> 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 test
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 Protecti
--
Date: Tue, 7 Oct 2014 23:12:47 +0530
From: Anand Neeli
> 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
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 [m
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 f
--
Date: Sat, 13 Sep 2014 05:33:29 +0800
From: Manikandan Govindaswamy
> 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
> app
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-optio
-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
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 ' ')
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'
li
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
check
--
Date: Thu, 07 Aug 2014 11:47:59 -0400
From: Alexandre Montplaisir
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 fro
--
Date: Wed, 06 Aug 2014 11:34:39 -0400
From: Alexandre Montplaisir
To: Simon Marchi , Jonathan Rajotte Julien
On 08/06/2014 10:49 AM, Simon Marchi wrote:
> Just by curiosity, did you manage to put a number on that performanc
--
Date: Thu, 31 Jul 2014 14:15:01 -0400
From: Jérémie Galarneau
To: Dmitri Shubin
>>> The arguments won't be evaluated if the event is not enabled.
>>> However, when an event is enabled, the arguments are evaluated
>>> regard
--
Date: Wed, 30 Jul 2014 17:58:25 +0400
From: Dmitri Shubin
> 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'
> enabl
--
Date: Mon, 28 Jul 2014 14:35:11 -0400
From: Jérémie Galarneau
To: RGIAS MUG
Cc: "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 wrote:
> >
--
Date: Sat, 19 Jul 2014 21:39:23 + (UTC)
From: Mathieu Desnoyers
Cc: Julien Desfossez
> For the curious, I implement this "filtering" with a per-channel bitmap that
> represents which system calls to trace.
> We might nee
--
Date: Mon, 7 Jul 2014 13:43:12 -0400
From: Shariyar
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
--
Date: Sun, 6 Jul 2014 18:49:51 -0400
From: Shariyar
> 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 generatin
--
Date: Wed, 2 Jul 2014 02:02:25 -0400
From: Sandeep K Chaudhary
> 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 numbe
--
Date: Wed, 25 Jun 2014 15:15:50 +0800
From: "zhenyu.ren"
> 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 queui
--
Date: Sun, 22 Jun 2014 19:27:31 +0400
From: Dmitri Shubin
> 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 fe
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
--
> 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
> 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 A
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
--
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
>>_trace
-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/incl
-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 a
--
Date: Wed, 4 Jun 2014 23:05:05 +
From: Randy Juillard
> Seems that your links for the documentation are broke on the web page:
>https://lttng.org/ust
>
> Randy Juillard
-
-Message d'origine-
De : Mathieu Desnoyers [mailto:mathieu.desnoy...@efficios.com]
Envoyé : 5 juin 2014 13:55
>>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 architect
--
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
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 h
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 boots
-Message d'origine-
De : Gerlando Falauto [mailto:gerlando.fala...@keymile.com]
Envoyé : 2 juin 2014 12:22
>> 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
-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
> TRACEPO
--
Date: Fri, 30 May 2014 11:54:02 -0400
From: Julien Desfossez
> [...]
> 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
> s
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.
Simples
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<--ESFSE
--
Date: Tue, 27 May 2014 13:34:20 +0200
From: Randy Wijnants
> 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 sessi
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 in
--
Date: Mon, 26 May 2014 11:27:35 +0200
From: Randy Wijnants
> 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
>
--
>> Date: Thu, 22 May 2014 18:21:29 +0200
>> From: Gerlando Falauto
>>
>>> 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
>>> tr
--
Date: Thu, 22 May 2014 18:21:29 +0200
From: Gerlando Falauto
> 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,
--
Date: Wed, 21 May 2014 12:10:24 -0400
From: Mathieu Desnoyers
To: David Goulet
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/co
-Message d'origine-
Envoyé : 8 mai 2014 07:26
> Thanks, I upgraded and this problem was fixed.
> But I noticed something new.
>
> When I run the "lttng list command" I get the events in different order from
> two locations I installed the new version.
> Did you encounter such an issue be
--
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 2
> > > 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 s
--
Date: Mon, 5 May 2014 08:24:39 +
From: "Sadon, Mirit"
Cc: "Eshel, Ayelet"
> I am working with the lttng trace to see how it affects are program
> performance,
> But if I don't limit the size of the trace file collected i
--
> Date: Fri, 2 May 2014 09:29:09 + (UTC)
> From: Mathieu Desnoyers
> To: Geneviève Bastien
> Yes, all this is about not repeating global type descriptions over the Unix
> socket between applications and session daemon.
>
Date: Wed, 30 Apr 2014 11:57:34 -0400
From: Marc-André Laperle
> 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:
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 overwhel
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) {
--
>> Date: Wed, 16 Apr 2014 18:22:42 +0200
>> From: S?bastien Barth?l?my
>>
>> 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
--
Date: Thu, 10 Apr 2014 14:43:38 -0400
From: Simon Marchi
Should be "[...] should not begin with '-' [...]" (although it is
true the size string should not *contain*, the test is only for
*begins with*)
> I
--
Date: Thu, 10 Apr 2014 11:30:19 -0400
From: Simon Marchi
+++ 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
--
Date: Tue, 8 Apr 2014 22:09:36 -0700
From: Sandeep K Chaudhary
To: David Goulet
Cc: "lttng-dev@lists.lttng.org"
> Here is the diff for changes made to the unit test. Please have a look.
--
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
--
> Date: Mon, 7 Apr 2014 13:43:21 +0200
> From: Jan Glauber
>
> 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_shar
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
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 i
--
Date: Fri, 04 Apr 2014 08:26:52 -0400
From: Francis Giraldeau
To: "zhenyu.ren"
> > 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_6
1 - 100 of 376 matches
Mail list logo
