[lttng-dev] [tracecompass-dev] Unreadable traces

[Matthew Khouzam]

Upon further inspection/reflexion, your clock was set at 0, but you are
probably in gmt-5, so you are in 1969 according to the trace, the trace
stores the offset as an unsigned long, so it relies on a rollover. I
would suggest that this is an undocumented feature in lttng. To be more
"correct" it would be nice if the clock offset were a signed long
instead of an unsigned one, this way we can handle the rather common
case of people in the east or west coast (or anywhere west of gmt-0)
working on embedded systems where their clocks are set to 0.

Any thoughts?

Matthew


On 14-12-19 11:11 AM, Matthew Khouzam wrote:
> Hi, this is  a very interesting trace!
>
> The clock offset is 18446744073709551571 ns, or 300 years in the future...
> babeltrace parses the date as follows [1969-12-31 19:13:09.028388290]
> (babeltrace --clock-date)
> tracecompass fails.
>
> How did you take this trace?
> I am kinda more comfortable keeping the trace failing for now, but if
> you have a use case where the clock can be offset by such a large
> number, please share the use case, I have a couple of ideas on how to
> extend it. :)
>
> BR
> Matthew
>
> PS. We love these test cases, keep em coming!
>
> On 14-12-19 09:28 AM, Gerlando Falauto wrote:
>> Hi,
>>
>> it's me again ;-)
>>
>> I'm playing around with Tracecompass and everything seems to be
>> working fine on a test platform.
>>
>> However, when tracing on the card we actually need to investigate, I
>> get unreadable traces. What happens is that I don't get the typical
>> mole icon under Tracing / Traces / Kernel after importing. Nor can I
>> double click on the icon and get the diagram.
>>
>> Attached are two trace instances where it's working and where it's
>> broken, respectively. Traces were obtained by running
>>
>> lttng create
>> lttng enable-event sched_switch,sched_wakeup -k
>> lttng start; lttng stop
>>
>> I tried to track it down and the culprit seems to be related to this
>> kernel setting:
>>
>> +CONFIG_RT_GROUP_SCHED=y
>>
>> Any ideas what could be wrong?
>>
>> Notice how babeltrace seems to work in both cases.
>>
>> Thank you!
>> Gerlando
>>
>>
>> _______________________________________________
>> tracecompass-dev mailing list
>> tracecompass-dev at eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev at eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev