* [ltt-dev] Flight-recording mode
[not found] ` <4EAE74A4.2000800@keymile.com>
@ 2011-11-01 18:41 ` Mathieu Desnoyers
2011-11-01 18:58 ` Gerlando Falauto
0 siblings, 1 reply; 6+ messages in thread
From: Mathieu Desnoyers @ 2011-11-01 18:41 UTC (permalink / raw)
* Gerlando Falauto (gerlando.falauto at keymile.com) wrote:
> On 10/28/2011 10:24 AM, Mathieu Desnoyers wrote:
>> * Gerlando Falauto (gerlando.falauto at keymile.com) wrote:
>>> On 10/28/2011 09:39 AM, Mathieu Desnoyers wrote:
>>>> * Gerlando Falauto (gerlando.falauto at keymile.com) wrote:
>>> ...
>>>>> How can I make sure that only the latest N seconds of traces will be
>>>>> saved? The answer should be flight-recording mode, but how do I really
>>>>> do it?
>>>>
>>>> I discussed this with David this morning, and we'll need to enhance
>>>> ltt-sessiond in lttng-tools to ensure it does not send the streams to
>>>> the consumer daemon upon trace start for overwrite mode channels, but
>>>> just on trace stop. This is lacking currently.
>>>
>>> OK, thanks!
>>> Does that also apply to LTTng 0.x (since I got the same impression)?
>>>
>>> For 0.x I came up with the idea of killing lttd but I don't know if
>>> a) it's a good idea;
>>> b) it would do the trick
>>
>> for 0.x it should all just work (TM) ;)
>
> Yeah, it sorta-kinda-most-of-the-times-almost works (R). :-)
:)
>
> I am having problems seeing those traces on LTTv though.
> I had to come up with a workaround by patching LLTv and doing some weird
> stuff after loading the trace in order to have LTTv not crash.
That's not supposed to be necessary. Which lttv version are you using ?
A gdb backtrace of the crash, with lttv compiled with make clean; make
CFLAGS=-g would be helpful.
>
> And also, half the times I cannot see some of the process names (of
> course, the ones I am really interested in). Is there any explanation
> for this?
The flight recording mode does not have the events of the statedump done
at the beginning of the trace. You might wait to try saving the
statedump-related events into separate channels, which are in "normal"
mode (not flight recorder).
>
>> by specifying flight recorder mode, lttctl is supposed to launch lttd
>> only on non-overwrite mode buffers (metadata) first, and only upon trace
>> teardown does it hook lttd on the flight recorder buffers.
>
> If you don't mind me asking, what's the point of having lttd running in
> background in that case (all channels in flight recorder mode)?
the metadata channel is always in "normal" mode (not flight recorder),
so we need a consumer to get the information as the trace is recorded.
Best regards,
Mathieu
>
> Thanks!
> Gerlando
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ltt-dev] Flight-recording mode
2011-11-01 18:41 ` [ltt-dev] Flight-recording mode Mathieu Desnoyers
@ 2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 18:58 ` Gerlando Falauto
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Gerlando Falauto @ 2011-11-01 18:58 UTC (permalink / raw)
On 11/01/2011 07:41 PM, Mathieu Desnoyers wrote:
>> I am having problems seeing those traces on LTTv though.
>> I had to come up with a workaround by patching LLTv and doing some weird
>> stuff after loading the trace in order to have LTTv not crash.
>
> That's not supposed to be necessary. Which lttv version are you using ?
> A gdb backtrace of the crash, with lttv compiled with make clean; make
> CFLAGS=-g would be helpful.
Actually, I had already sent a trace which breaks lttv to Alexandre.
He was able to reproduce it and said he forwarded it To Whom It May
Concern (R).
Anyway, you can find it attached, and here is my "report":
============================
If you delete flight-irq-state_0 (so you're left off with metadata_0
alone) everything works fine.
As soon as you add it back, lttv crashes on load.
I also have found (by chance of course) a complicated workaround, if you
want to make a comparison. Just do as follows:
- untargz lttv
- ./configure && make
- Apply the attached patch
- Run make && sudo make install
- Open lttv
- Destroy the control flow viewer
- Open the trace
- DO NOT TOUCH ANYTHING, just click on the "New window icon"
- Work on the newly opened window, and LEAVE THE FIRST WINDOW ALONE!!!
As soon as you click on some event on the first window, the application
will crash.
============================
>> And also, half the times I cannot see some of the process names (of
>> course, the ones I am really interested in). Is there any explanation
>> for this?
>
> The flight recording mode does not have the events of the statedump done
> at the beginning of the trace. You might wait to try saving the
> statedump-related events into separate channels, which are in "normal"
> mode (not flight recorder).
Sorry, I don't understand your last sentence. If you mean "you might
WANT to...", how do I do that?
>>> by specifying flight recorder mode, lttctl is supposed to launch lttd
>>> only on non-overwrite mode buffers (metadata) first, and only upon trace
>>> teardown does it hook lttd on the flight recorder buffers.
>>
>> If you don't mind me asking, what's the point of having lttd running in
>> background in that case (all channels in flight recorder mode)?
>
> the metadata channel is always in "normal" mode (not flight recorder),
> so we need a consumer to get the information as the trace is recorded.
Uhm, so the consumer is needed all along? (i.e., it also records
information during the trace, not only at startup?)
Thanks!
Gerlando
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace.broken.tgz
Type: application/x-compressed-tar
Size: 4025 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20111101/d135c97b/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: workaround.patch
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20111101/d135c97b/attachment.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ltt-dev] Flight-recording mode
2011-11-01 18:58 ` Gerlando Falauto
@ 2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 19:46 ` Mathieu Desnoyers
2 siblings, 0 replies; 6+ messages in thread
From: Gerlando Falauto @ 2011-11-01 18:58 UTC (permalink / raw)
On 11/01/2011 07:41 PM, Mathieu Desnoyers wrote:
>> I am having problems seeing those traces on LTTv though.
>> I had to come up with a workaround by patching LLTv and doing some weird
>> stuff after loading the trace in order to have LTTv not crash.
>
> That's not supposed to be necessary. Which lttv version are you using ?
> A gdb backtrace of the crash, with lttv compiled with make clean; make
> CFLAGS=-g would be helpful.
Actually, I had already sent a trace which breaks lttv to Alexandre.
He was able to reproduce it and said he forwarded it To Whom It May
Concern (R).
Anyway, you can find it attached, and here is my "report":
============================
If you delete flight-irq-state_0 (so you're left off with metadata_0
alone) everything works fine.
As soon as you add it back, lttv crashes on load.
I also have found (by chance of course) a complicated workaround, if you
want to make a comparison. Just do as follows:
- untargz lttv
- ./configure && make
- Apply the attached patch
- Run make && sudo make install
- Open lttv
- Destroy the control flow viewer
- Open the trace
- DO NOT TOUCH ANYTHING, just click on the "New window icon"
- Work on the newly opened window, and LEAVE THE FIRST WINDOW ALONE!!!
As soon as you click on some event on the first window, the application
will crash.
============================
>> And also, half the times I cannot see some of the process names (of
>> course, the ones I am really interested in). Is there any explanation
>> for this?
>
> The flight recording mode does not have the events of the statedump done
> at the beginning of the trace. You might wait to try saving the
> statedump-related events into separate channels, which are in "normal"
> mode (not flight recorder).
Sorry, I don't understand your last sentence. If you mean "you might
WANT to...", how do I do that?
>>> by specifying flight recorder mode, lttctl is supposed to launch lttd
>>> only on non-overwrite mode buffers (metadata) first, and only upon trace
>>> teardown does it hook lttd on the flight recorder buffers.
>>
>> If you don't mind me asking, what's the point of having lttd running in
>> background in that case (all channels in flight recorder mode)?
>
> the metadata channel is always in "normal" mode (not flight recorder),
> so we need a consumer to get the information as the trace is recorded.
Uhm, so the consumer is needed all along? (i.e., it also records
information during the trace, not only at startup?)
Thanks!
Gerlando
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace.broken.tgz
Type: application/x-compressed-tar
Size: 4025 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20111101/d135c97b/attachment-0003.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: workaround.patch
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20111101/d135c97b/attachment-0002.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ltt-dev] Flight-recording mode
2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 18:58 ` Gerlando Falauto
@ 2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 19:46 ` Mathieu Desnoyers
2 siblings, 0 replies; 6+ messages in thread
From: Gerlando Falauto @ 2011-11-01 18:58 UTC (permalink / raw)
On 11/01/2011 07:41 PM, Mathieu Desnoyers wrote:
>> I am having problems seeing those traces on LTTv though.
>> I had to come up with a workaround by patching LLTv and doing some weird
>> stuff after loading the trace in order to have LTTv not crash.
>
> That's not supposed to be necessary. Which lttv version are you using ?
> A gdb backtrace of the crash, with lttv compiled with make clean; make
> CFLAGS=-g would be helpful.
Actually, I had already sent a trace which breaks lttv to Alexandre.
He was able to reproduce it and said he forwarded it To Whom It May
Concern (R).
Anyway, you can find it attached, and here is my "report":
============================
If you delete flight-irq-state_0 (so you're left off with metadata_0
alone) everything works fine.
As soon as you add it back, lttv crashes on load.
I also have found (by chance of course) a complicated workaround, if you
want to make a comparison. Just do as follows:
- untargz lttv
- ./configure && make
- Apply the attached patch
- Run make && sudo make install
- Open lttv
- Destroy the control flow viewer
- Open the trace
- DO NOT TOUCH ANYTHING, just click on the "New window icon"
- Work on the newly opened window, and LEAVE THE FIRST WINDOW ALONE!!!
As soon as you click on some event on the first window, the application
will crash.
============================
>> And also, half the times I cannot see some of the process names (of
>> course, the ones I am really interested in). Is there any explanation
>> for this?
>
> The flight recording mode does not have the events of the statedump done
> at the beginning of the trace. You might wait to try saving the
> statedump-related events into separate channels, which are in "normal"
> mode (not flight recorder).
Sorry, I don't understand your last sentence. If you mean "you might
WANT to...", how do I do that?
>>> by specifying flight recorder mode, lttctl is supposed to launch lttd
>>> only on non-overwrite mode buffers (metadata) first, and only upon trace
>>> teardown does it hook lttd on the flight recorder buffers.
>>
>> If you don't mind me asking, what's the point of having lttd running in
>> background in that case (all channels in flight recorder mode)?
>
> the metadata channel is always in "normal" mode (not flight recorder),
> so we need a consumer to get the information as the trace is recorded.
Uhm, so the consumer is needed all along? (i.e., it also records
information during the trace, not only at startup?)
Thanks!
Gerlando
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace.broken.tgz
Type: application/x-compressed-tar
Size: 4025 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20111101/d135c97b/attachment-0002.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: workaround.patch
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20111101/d135c97b/attachment-0001.asc>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ltt-dev] Flight-recording mode
2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 18:58 ` Gerlando Falauto
@ 2011-11-01 19:46 ` Mathieu Desnoyers
2 siblings, 0 replies; 6+ messages in thread
From: Mathieu Desnoyers @ 2011-11-01 19:46 UTC (permalink / raw)
* Gerlando Falauto (gerlando.falauto at keymile.com) wrote:
> On 11/01/2011 07:41 PM, Mathieu Desnoyers wrote:
>
>>> I am having problems seeing those traces on LTTv though.
>>> I had to come up with a workaround by patching LLTv and doing some weird
>>> stuff after loading the trace in order to have LTTv not crash.
>>
>> That's not supposed to be necessary. Which lttv version are you using ?
>> A gdb backtrace of the crash, with lttv compiled with make clean; make
>> CFLAGS=-g would be helpful.
>
> Actually, I had already sent a trace which breaks lttv to Alexandre.
> He was able to reproduce it and said he forwarded it To Whom It May
> Concern (R).
> Anyway, you can find it attached, and here is my "report":
>
> ============================
> If you delete flight-irq-state_0 (so you're left off with metadata_0
> alone) everything works fine.
> As soon as you add it back, lttv crashes on load.
>
> I also have found (by chance of course) a complicated workaround, if you
> want to make a comparison. Just do as follows:
>
> - untargz lttv
> - ./configure && make
> - Apply the attached patch
> - Run make && sudo make install
> - Open lttv
> - Destroy the control flow viewer
> - Open the trace
> - DO NOT TOUCH ANYTHING, just click on the "New window icon"
> - Work on the newly opened window, and LEAVE THE FIRST WINDOW ALONE!!!
>
> As soon as you click on some event on the first window, the application
> will crash.
> ============================
>
>>> And also, half the times I cannot see some of the process names (of
>>> course, the ones I am really interested in). Is there any explanation
>>> for this?
>>
>> The flight recording mode does not have the events of the statedump done
>> at the beginning of the trace. You might wait to try saving the
>> statedump-related events into separate channels, which are in "normal"
>> mode (not flight recorder).
>
> Sorry, I don't understand your last sentence. If you mean "you might
> WANT to...", how do I do that?
>
>>>> by specifying flight recorder mode, lttctl is supposed to launch lttd
>>>> only on non-overwrite mode buffers (metadata) first, and only upon trace
>>>> teardown does it hook lttd on the flight recorder buffers.
>>>
>>> If you don't mind me asking, what's the point of having lttd running in
>>> background in that case (all channels in flight recorder mode)?
"want", yes. This can be done by specifying that the "state" channel
should be in non-overwrite mode. You'll have to look into lttctl option
parameters to specify different behavior on a per-channel basis.
>>
>> the metadata channel is always in "normal" mode (not flight recorder),
>> so we need a consumer to get the information as the trace is recorded.
>
> Uhm, so the consumer is needed all along? (i.e., it also records
> information during the trace, not only at startup?)
If you load a module while tracing is active, you need to add
information about the events located in the loaded modules to the
metadata.
Sorry I don't have time to look into the lttv crash. Focusing on UST 2.0
for now.
Best regards,
Mathieu
>
> Thanks!
> Gerlando
> diff -Nur lttv-0.12.38-21032011/lttv/modules/gui/detailedevents/events.c lttv-0.12.38-21032011.mine/lttv/modules/gui/detailedevents/events.c
> --- lttv-0.12.38-21032011/lttv/modules/gui/detailedevents/events.c 2011-01-25 16:29:18.000000000 +0100
> +++ lttv-0.12.38-21032011.mine/lttv/modules/gui/detailedevents/events.c 2011-10-20 17:07:28.000682000 +0200
> @@ -518,7 +521,7 @@
> if(event_viewer_data->background_info_waiting == 0) {
> g_message("event viewer : background computation data ready.");
>
> - evd_redraw_notify(event_viewer_data, NULL);
> + //evd_redraw_notify(event_viewer_data, NULL);
> }
>
> return 0;
> diff -Nur lttv-0.12.38-21032011/lttv/lttv/lttv-gui lttv-0.12.38-21032011.mine/lttv/lttv/lttv-gui
> --- lttv-0.12.38-21032011/lttv/lttv/lttv-gui 2011-10-21 10:38:06.000234000 +0200
> +++ lttv-0.12.38-21032011.mine/lttv/lttv/lttv-gui 2011-10-20 17:06:23.000083000 +0200
> @@ -6,6 +6,8 @@
>
> LTTV_CMD=`echo $0 | sed 's/-gui$//'`
>
> -$LTTV_CMD.real -m lttvwindow -m guievents -m guifilter -m guicontrolflow -m resourceview \
> - -m guistatistics -m guitracecontrol $*
> +#$LTTV_CMD.real -m lttvwindow -m guievents -m guifilter -m guicontrolflow -m resourceview \
> +# -m guistatistics -m guitracecontrol $*
> +$LTTV_CMD.real -m lttvwindow -m guievents -m guicontrolflow \
> + $*
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ltt-dev] Flight-recording mode
[not found] ` <20111028073928.GA4855@Krystal>
[not found] ` <4EAA65CB.5010009@keymile.com>
@ 2011-11-10 8:06 ` Gerlando Falauto
1 sibling, 0 replies; 6+ messages in thread
From: Gerlando Falauto @ 2011-11-10 8:06 UTC (permalink / raw)
On 10/28/2011 09:39 AM, Mathieu Desnoyers wrote:
> * Gerlando Falauto (gerlando.falauto at keymile.com) wrote:
[...]
>> How can I make sure that only the latest N seconds of traces will be
>> saved? The answer should be flight-recording mode, but how do I really
>> do it?
>
> I discussed this with David this morning, and we'll need to enhance
> ltt-sessiond in lttng-tools to ensure it does not send the streams to
> the consumer daemon upon trace start for overwrite mode channels, but
> just on trace stop. This is lacking currently.
>
> Thanks for reporting this!
No pressure but... any news on this topic? O:-D
Could you suggest at least a hard-coded workaround?
Thanks!
Gerlando
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-11-10 8:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <4EA9A8ED.2010303@keymile.com>
[not found] ` <20111028073928.GA4855@Krystal>
[not found] ` <4EAA65CB.5010009@keymile.com>
[not found] ` <20111028082448.GA11499@Krystal>
[not found] ` <4EAE74A4.2000800@keymile.com>
2011-11-01 18:41 ` [ltt-dev] Flight-recording mode Mathieu Desnoyers
2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 18:58 ` Gerlando Falauto
2011-11-01 19:46 ` Mathieu Desnoyers
2011-11-10 8:06 ` Gerlando Falauto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox