[ltt-dev] Bug in LTTv statistics ?

[François Godin]

2010/7/7 Mathieu Desnoyers <compudj at krystal.dyndns.org>

> * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> > * Copelnug (copelnug at gmail.com) wrote:
> > > There seems to be a bug in the LTTv statistics.
> > >
> > > The problems is visible in the function "every_event" of the
> lttv/stats.c
> > > file. That function is called for each event and receive a
> > > "LttvTracefileStats" structure as parameter.
> > >
> > > So if you check the value of the pointer to the "LttvTracefileStats"
> > > received, you can see it changing between 15 and 20 value depending of
> the
> > > trace loaded. This seems to be intended to me because each type of
> events is
> > > associated with one and only one "LttvTracefileStats" (but a structure
> can
> > > have many events type).
> > >
> > > The bug seems to be a side effect : The structure passed to the
> function
> > > contain the current path to the "current_event_types_tree" that is used
> to
> > > increase the numbers of event for the event type. Or, this value is not
> > > conserved between two "LttvTracefileStats" which means that the change
> of
> > > process or state only affect one "LttvTracefileStats" and let the
> others to
> > > their value. That means that some types of event are never affected by
> a
> > > change of mode or process.
> > >
> > > What this cause is :
> > > - Many event in process 0 and Unknown mode.
> > > - Difference between the total for a process of the event list in the
> > > textdump and the value for the process in the statistics of the same
> > > textdump.
> > >
> > > Is it really a problem or am I misunderstanding something ?
> >
> > Ack, I'm currently digging in the stats code to try to fix the problem.
> > Thanks for the precise bug report.
>
> OK, very light testing seems to show that the fix I just did helps a
> lot. Can you try the lttv version at the head of the git repo ?
>
> git clone git://lttng.org/lttv.git
>
> Then make sure you got my latest commit:
>
> cd lttv
> git show 516a8712d079429962523e033e28f68704bc770a
>
> Please follow the quickstart guide for installation, in summary:
>
> ./autogen.sh --prefix=path_to_install CFLAGS=-g
> make
> make install
>
> I'll wait for your feedback before pushing a new release.
>
> Thanks,
>
> Mathieu
>
>
I've tested it and the result are coherent between the event list of the
textdump and the statistics given by it. So the fix is definitely working.

But, as I've looked in the event list of the textdump, I've seens something
that could maybe trigger a bug. The core_marker_* events at the start where
mixed with some other events. In this case, there were no sched_schedule,
but it could maybe happen. So the questions are : Are all core_marker_*
supposed to be unknown ?  Are the process_state suppose to trigger a change
to process 0 ? Are all event between process the last process_state and the
next sched_schedule suppose to be at process 0 ? And is this covered in the
code  or impossible to happen ?


-- 
François Godin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100708/460dc134/attachment-0003.htm>