-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniel,
Yes, in any case, we block so this flag is our best option for now to handle all
the data.
Good catch by the way! Thanks for the help and report! I'll put in the patch for
the release candidate 1.
Thanks!
David
On 12-01-24 09:37 AM, Thib
-Message d'origine-
De : David Goulet [mailto:david.gou...@polymtl.ca]
Envoyé : 23 janvier 2012 17:43
> That's very interesting.
>
> Quick fix, let see if it works:
>
> diff --git a/src/common/sessiond-comm/sessiond-comm.c
> b/src/common/sessiond-comm/sessiond-comm.c
> index 03e8931..106
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
That's very interesting.
Quick fix, let see if it works:
diff --git a/src/common/sessiond-comm/sessiond-comm.c
b/src/common/sessiond-comm/sessiond-comm.c
index 03e8931..106041f 100644
- --- a/src/common/sessiond-comm/sessiond-comm.c
+++ b/src/common/
I've narrowed it down to lttng-ctl.ask_sessiond(): the first
recv_data_sessiond() call expects 16 bytes (sizeof(llm)) and gets 16 bytes.
llm.data_size holds the payload size (in bytes), which is what the second
recv_data_sessiond() call expects...But it receives only 15 984 bytes of the
exp
Of potential interest is the session log when I proceeded to kill
lttng-sessiond (which had processed only the list -k command):
DEBUG1: SIGTERM catched [in sighandler() at main.c:4179]
DEBUG1: Terminating all threads [in stop_threads() at main.c:400]
DEBUG1: Futex n to 1 wake done [in futex_n
> You have the exact same output as mine.
>
> 51 events is correct and the return data size is 41224. We'll have to add
> debug
> output. Let's check the event name returned by the kernel and those we send
> back. Please add this to the git head of lttng-tools:
>
> +++ b/src/bin/lttng-sessiond/ker
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniel,
You have the exact same output as mine.
51 events is correct and the return data size is 41224. We'll have to add debug
output. Let's check the event name returned by the kernel and those we send
back. Please add this to the git head of lt
> This is very odd...
>
> The "DEBUG1: SIGCHLD catched [in sighandler() at lttng.c:179]" shows you that
> when this signal is caught by the lttng client, it means that the session
> daemon
> is ready hence the lttng modules are loaded for sure. The session daemon send
> this signal only when it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is very odd...
The "DEBUG1: SIGCHLD catched [in sighandler() at lttng.c:179]" shows you that
when this signal is caught by the lttng client, it means that the session daemon
is ready hence the lttng modules are loaded for sure. The session daemon
> Can you please try this commit :
> commit 6725fe1993a3c70c5fddecf5a458f03b08852edd
> Date: Fri Jan 20 15:07:15 2012 -0500
> Fix off-by-one and double list size instead of steady increment
No problem. In both senses of the expression: bootstrap, config, make,
install went without a problem
Hi Daniel,
What is your lttng-modules git commit ID ?
And we will need your full kernel .config file to see what CONFIG_*
options are enabled.
Thanks,
Mathieu
* David Goulet (david.gou...@polymtl.ca) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Daniel,
>
> On 12-01-18 02:1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Daniel,
On 12-01-18 02:12 PM, Thibault, Daniel wrote:
>
>Well, the good news is that the new head (lttng-tools-2.0-pre16+-76150f6
> 2012-01-18 17:21) compiles correctly (no warnings, no errors in bootstrap,
> configure, make and install logs
De : David Goulet [mailto:david.gou...@polymtl.ca]
>
> I just pushed a fix with the auto spawned session daemon but not related
> to your problem.
>
> Is it possible for you to test with the latest git head of lttng-tools
> because since the commit 9beed4c there is a large number of fixes!
>
> T
Hi Daniel,
I just pushed a fix with the auto spawned session daemon but not related
to your problem.
Is it possible for you to test with the latest git head of lttng-tools
because since the commit 9beed4c there is a large number of fixes!
The session daemon sends a signal to the parent (her
When the lttng-sessiond daemon is first spawned to process a 'list -k'
command, some of the kernel events are given as anonymous. Repeating the
request a second time obtains the kernel event names correctly. This is
repeatable, in the sense that it always occurs and the anonymised kernel ev
15 matches
Mail list logo
