* [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: 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: 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