[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Extending filtering for CallStackView
|
Patrick
Each trace has two analysis that I specified, which are using the full history state system, backed to disk. These files are ending up in subdirectories of the .temp directory in my workspace, where each analysis file has a filename consisting of the analysis module ID with '.ht' appended.
The analysis output for each trace ends up in a subdirectory named using the name of the trace as returned by getName(), so each analysis file is a unique file. I'm thinking that I'm failing to call some method that closes and releases the resources associated with an analysis.
My directory structure looks like
.temp
trace1
analysisA.ht
analysisB.ht
trace2
analysisA.ht
analysisB.ht
Dave
Patrick Tasse ---08/10/2016 03:19:03 PM---Hi Dave, I would try it with wrapped traces instead of cloned traces.
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/10/2016 03:19 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
Hi Dave,
I would try it with wrapped traces instead of cloned traces.
If I understand correctly, your trace has two call stack analyses. Are they using different output files for the state system? If they are using the same file it might explain some of the problems.
In your overloaded CallStackView.getTracesToBuild(), create a new list and for each trace returned by the super.getTracesToBuild() (in case of an experiment with multiple traces), if it is one of your traces create two wrappers around the original trace, and add them to the list of traces to build.
The wrappers could just be a subclass of TmfTrace that have the original trace as a private field, and another field to indicate which analysis it should use.
Override getName() to append something (the selected analysis number?) to the original trace name (so you can use that in your filtering content provider).Override getAnalysisModules() so that it returns only the call stack analysis from the original trace that corresponds to the selected analysis.Override getFunctionName() so that it returns whatever the original trace returns.I think you can return anything for all the other abstract methods that need to be implemented, I don't think the call stack view (the only object that has visibility to those wrappers) will call anything else on them.
Patrick
On Mon, Aug 8, 2016 at 5:56 PM, David Wootton <dwootton@xxxxxxxxxx> wrote:Patrick
It looks like this approach to preserving filtering may not be practical.
Once I fixed the trace name so the IOException and TMFTraceException no longer occurred, I still was not able to get my 2nd analysis data to display.
In trying to debug by stepping thru CallStackView.buildEntryList, it seems that the processing to build the set of TimeGraphEntry objects does not result in any ProcessEntry, ThreadEntry, or lower level objects being created, only the TraceEntry object with no children, which explains the blank view.
There seems to be something wrong with the state system for this analysis resulting in the failure to create Process Entry, ThreadEntry, etc objects. I don't know if there is an assumption that the trace events used as input to the analysis are owned by the same trace object as the one I'm trying to use in my view or if something else is going wrong. I did try to clone a new set of events with ownership set to the new trace but that didn't seem to help.
I also suspect this has something to do with the tree in the left hand side of the CallStackView not populating properly even when the intervals do display (in my first trace/analysis). I haven't tracked down the code which manages the creation of this tree.
Another problem I discovered is that something in the code is not closing the files that contain the state system data in the full history model. This means that even if I reload the trace, I cannot regenerate the analysis data, since the attempt to rewrite these files fails somewhere with a 'files in use IOException'. at least on Windows. I can clean up the analysis data files for the original trace after ensuring the trace editor view for the trace is closed, but I have no editor for the second trace.
If you have suggestions for something else to try, I'll try them.
Otherwise I think I need to accept that being unable to preserve filtering is a limitation in the current release.
Thanks for your help.
Dave
David Wootton---08/04/2016 05:59:33 PM---Patrick I created a scratch workspace this afternoon containing my plugin source +
From: David Wootton/Poughkeepsie/Contr/IBM@IBMUS
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/04/2016 05:59 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
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:_______________________________________________
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
_______________________________________________
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