[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Extending filtering for CallStackView
|
Patrick
I did most of what you suggested. I could not override getFunctionName(), by which I assumed you meant CallStackView.getFunctionName() since it's access is package-private and not visible to my class extending CallStackView. I don't think this matters since I'm not doing anything in my implementation with function names at this point.
Once I did this, I am able to open a trace, then switch between analysis 'A' and analysis 'B' as well as load a second trace and switch between its analysis 'A' and analysis 'B' without problems.
If I apply a filter to analysis 'A', switch to analysis 'B' and then switch back to analysis 'A' the filtering for analysis 'A' is preserved.
However, if I switch to analysis 'B' again, set a filter for analysis 'B', then filtering is applied to analysis 'B' correctly. However, when I switch back to analysis 'A', its filtering is reset and all threads are visible. If I set a new filter for analysis 'A' then switch to analysis 'B', the filtering for analysis 'B' is reset.
I did set a breakpoint at the point in getElements() where I return the array of TraceEntry objects (a single object) and walk thru the tree from the TraceEntry object down to the ThreadEntry objects, noting the object id (id=nnn) in the debugger. It looks like the tree is not being modified as te object ids remain the same at that point. Maybe a tree elsewhere is being reconstructed, clearing the filtering?
The other problem I'm still seeing is that the tree on the left side of the view that shows the trace, process and thread entries shows no child elements for the thread elements, so a thread element is not expandable/collabsible even though the timeline showing the intervals for the ThreadEntry object are always shown. So there's something else I'm missing that causes the tree to be incorrectly constructed.
Dave
Patrick Tasse ---08/10/2016 03:25:48 PM---> The wrappers could just be a subclass of TmfTrace that have the original trace as a private field,
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/10/2016 03:25 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
> 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.
Probably simpler:
Call TmfTraceUtils.getAnalysisModulesOfClass(trace, AbstractCallStackAnalysis.class) on your trace, and for each returned call stack analysis, create a different wrapper and store the analysis as a field in the wrapper. Then each wrapper can return that single analysis in its overridden getAnalysisModules().
Patrick
On Wed, Aug 10, 2016 at 3:18 PM, Patrick Tasse <patrick.tasse@xxxxxxxxx> wrote: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