[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Extending filtering for CallStackView
|
Patrick
I created a scratch workspace this afternoon containing my plugin source + Trace Compass source. It turns out the reason the analysis modules were not loading was that CallStackView.getCallStackModule() was returning null due to a TmfTraceException that was in turned caused by an IOException. The cause of the IOException was the way I build the alternate name for the cloned trace. I appended ':' and the analysis module ID. Since I'm using a full (disk) state system, the ':' was part of the filename, which is invalid on Windows.
Once I fixed that, I don't have that problem, and the state system history files created on disk are each 69KB, so there is data in them. However, the view does not display any intervals, so I need to do some more debugging.
It also turns out the reason I thought the thread numbers were displaying as ':' is that the Function column was not quite wide enough by default to display the number, so the text was clipped. Once I widened the column, the numbers were visible.
There was an additional problem which I didn't realize, that with my modifications, the tree does not properly align with the timelines. The indicators I can click to expand and collapse a timeline are gone, so the tree with thread numbers is fully collapsed, as if some child nodes are missing.
I'm off now, and on Fridays, so I will continue debugging on Monday.
Dave
Patrick Tasse ---08/04/2016 05:44:17 PM---Hi Dave, 1) When I switch to my second analysis, the view updates, but no intervals
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/04/2016 05:44 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
Hi Dave,
1) When I switch to my second analysis, the view updates, but no intervals are shown and the tree in the left hand side of my view, where the processes and threads tree would be shown only has a line 'Stack info not available ...'. It looks like this results from two places in CallStackView.buildEntryList, when the result of getCallStackModule() is null and when module.getStateSystem() returns null. As far as I can tell by debugging, getAnalysisModules() should be returning an analysis module since my implementation of TmfTrace.getAnalysisModules() is returning a list of modules, and my modules have a valid state system in the fStateSystem field.
I suspect your cloned trace doesn't have its fAnalysisModules set, maybe executeAnalysis() was never called on it, but should it, or should it reuse the original's trace analyses?
2) When my first analysis displays, showing thread timelines, the thread id in the process/thread tree is a ':' instead of a thread number.
That should come from the state system's attribute name, is it the same you see in the State System Explorer view?
I think my two trace objects (original and clone) have to have unique names. When the TraceEntry objects are created they are assigned the trace name. So if the names are the same I have no way to tell the TraceEntry objects apart in TimeGraphContentProvider.getElements();
Indeed, the TraceEntry doesn't have any reference to the ITmfTrace object. Perhaps you can have an algorithm that filters out the n'th occurrence of trace entries with the same name, where 'n' depends on the selected analysis?
One thing I ran into when trying to add events to an existing trace is that the TmfEvent objects contain a reference to the trace that contains them. In order to be able to add events, I had to create a new trace and then create new TmfEvent objects to add to the new trace. I don't know if anything is looking at TmfEvents in the process of building the data for the CallStackView and failing.
The Call Stack view only uses the data from the state system provided by the module, it does not read the trace events itself.
The module reads events to build the state system, but this should happen before the changes you are doing here.
Patrick On Thu, Aug 4, 2016 at 12:13 PM, David Wootton <dwootton@xxxxxxxxxx> wrote:Patrick
I think I've done what you suggested and have this partially working. If I switch between analyses the view does update, and the filtering of thread timelines is preserved.
However, I have two problems at this point
1) When I switch to my second analysis, the view updates, but no intervals are shown and the tree in the left hand side of my view, where the processes and threads tree would be shown only has a line 'Stack info not available ...'. It looks like this results from two places in CallStackView.buildEntryList, when the result of getCallStackModule() is null and when module.getStateSystem() returns null. As far as I can tell by debugging, getAnalysisModules() should be returning an analysis module since my implementation of TmfTrace.getAnalysisModules() is returning a list of modules, and my modules have a valid state system in the fStateSystem field.
2) When my first analysis displays, showing thread timelines, the thread id in the process/thread tree is a ':' instead of a thread number.
In order to do this, I implemented a copy constructor for my TmfTrace class and then cloned the initial trace, setting the cloned trace such that it returned the analysis module for the second analysis and giving it a unique name.
The wrapper class contains my initial trace object and the cloned trace object, and depending on which analysis I want to view, determines which trace object to query. My wrapper class also extends TmfTrace, where the methods I had to implement are just passthrus to the selected trace object. My wrapper trace object also has a unique name.
I think my two trace objects (original and clone) have to have unique names. When the TraceEntry objects are created they are assigned the trace name. So if the names are the same I have no way to tell the TraceEntry objects apart in TimeGraphContentProvider.getElements();
One thing I ran into when trying to add events to an existing trace is that the TmfEvent objects contain a reference to the trace that contains them. In order to be able to add events, I had to create a new trace and then create new TmfEvent objects to add to the new trace. I don't know if anything is looking at TmfEvents in the process of building the data for the CallStackView and failing.
Dave
Patrick Tasse ---08/03/2016 01:32:01 PM---Hi Dave, 1) I actually meant the view's content provider (you can call
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/03/2016 01:32 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
Hi Dave,
1) I actually meant the view's content provider (you can call setTimeGraphContentProvider from the constructor), but you'd probably also need to call setFilterContentProvider and change that one too.
Yes what I had in mind is to override getElements(Object input) which receives the root (trace) entry list as input so that it returns a reduced array of trace entries.
2) Wrapping or copying the trace looks like the hardest part. But looking at the Call Stack view code, it looks like we actually don't need much from that trace. It needs to handle methods ITmfTrace.getName(), and it needs to be able to be used as input parameter to CallStackView.getCallStackModule() and CallStackView.getFunctionName(). I might be wrong, but if you have those covered you might not need to really worry about anything else from ITmfTrace in your wrapper.
3) I guess either the traces/wrappers have both modules and getCallStackModule() returns the right one, or each trace/wrapper returns the single correct module. Whatever works best ;)
Patrick
On Wed, Aug 3, 2016 at 12:48 PM, David Wootton <dwootton@xxxxxxxxxx> wrote:_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev