[ltt-dev] lttv-gui known problem list?

[Mathieu Desnoyers]

* Steve Langstaff (steve.langstaff at pebblebay.com) wrote:
> Hi all.
> 

Hi Steve,

> Is there a known problem list for lttv-gui?
> 

There are some known limitations in the LTTV roadmap :

http://ltt.polymtl.ca/svn/trunk/lttv/doc/developer/lttng-lttv-roadmap.html

Buried in the LTTng website under :

Documentation/Dev Doc/Various LTTng and LTTV Developer Documents

But it's by no mean complete.

> I am just getting to grips with LTTV and, though it seems to have the
> potential
> to be a useful tool, I have noticed a couple of issues with version
> 0.12.14-15052009 (which I am using with LTTng 0.124) and wondered whether
> there
> is anything obvious that I am doing wrong.
> 
> The issues I have seen are:
> 
> 1) Trace parsing
> 
> It seems that sometimes (maybe 2 out of 3 times) trace parsing does not
> work correctly - processes that I know are in the trace are not displayed,
> or if they are then the trace duration appears incorrect, or their names
> are missing.
> 
> The trace summary is interesting for these 'good' and 'bad' parses of
> the same trace:
> 
> BAD:
> 
> Statistic for  '/home/steve/Projects/lttng/traces/trace3' :
> 
> statistics summed :  1
> events count :  15938
> cpu time :          14.099272461
> elapsed time (includes per process waiting time) :          32.392476059
> cumulative cpu time (includes nested routines and modes) :
> 14.094529298
> 
> GOOD:
> 
> Statistic for  '/home/steve/Projects/lttng/traces/trace3' :
> 
> statistics summed :  1
> cpu time :           0.000000525
> events count :  15938
> elapsed time (includes per process waiting time) :           0.000001207
> cumulative cpu time (includes nested routines and modes) :
> 0.000000525

Is this problem only visible within the "statistics" view ? Is the
"control flow" view also affected or does it work correctly ?

> 
> --
> 
> 2) Lockup
> 
> Sometimes lttv-gui locks up, using more than 95% of my CPU (according to
> 'top').
> 
> I *think* that this happens when I scroll back within a trace (but this
> may be a side-effect of the trace parsing badness above).

This is probably the detailed event list. When you scroll backward,
there is an evolved algorithm to seek backward in the trace which can
require, in the worse case, to parse the entire trace. The worse case
would be to scroll backward with a filter applied which would have to
seek back to the beginning of the trace to get the information. It
iteratively try to get the information it needs within the time frame
prior to the currently shown interval, but if it can't, then it doubles
the time frame to look at and reads a larger section of the trace, and
doubles the time window incrementally until it finds all the information
or until it reaches the beginning of the trace.

As you see, this might be CPU consuming. And the detailed event list
blocks the whole GUI while doing this.

> 
> --
> 
> 3) Selection of trace
> 
> The "select a trace" dialog uses a "file selection" dialog to select a
> directory
> (rather than a file) so one has to type in a directory name when one is in
> the
> parent directory - it took me a few attempts before I guessed the magic
> incantation.

Or you can double-click on the trace directory, and you would be all set
(I think ?). But I agree this is weird.

> 
> The rest of the tool is navigable using the mouse, so this forced use of the
> keyboard is a shame.
> 

Thanks for reporting those problems. If you find time to fix them,
patches are welcome. :)

Mathieu

> 
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68