Hi Daniel, For the Files subsystem, I see the same behavior. This is untouched functionality provided by the Target Management / Remote Systems Explorer plugins. I tried to debug a little to see what is happening, it seems that when you expand the "Home" filter, the filter string is "." which gets somehow translated to "root", and what you end up seeing is the contents of "/root". On my machine that directory only contains hidden files so the expanded "Home" filter is empty. When I expand the "Root" filter which is "/", I see one of the items is the "root" subdirectory, and it is also empty if I expand it. Personally I just don't use the "Home" filter...
For your problems with trace control, I suspect that when you create the new trace there is an exception thrown, since if it were successful a RemoteResourceChangedEvent would have been fired at the end and the new trace should appear under the target "0". The error should be logged in <workspace>/.metadata/.plugins/org.eclipse.rse.ui/.log, or perhaps <workspace>/.metadata/.log. It should also be displayed in the General > Error Log view in Eclipse. We probably should enhance the error handling so that a message is shown to the user on such errors... When you refresh the "All Providers" node, the command getTraces is used. This only returns the name of the traces from the LTT control directory (ex: /mnt/debugfs/ltt/control), but it has no information about the trace configuration, this is why you must reconfigure it. The configuration can only be retrieved for active traces, which are those that have a lttd daemon currently running (this is triggered by a successful writeTraceLocal or writeTraceNetwork). I guess your Start is also failing, let's see what the .log says? Are you by any chance reusing an old trace name which is not properly cleaned up on your target? The command getActiveTraces doesn't tell us if the trace is running or not (ie. started or paused). I have a working solution for that in my development code, but it requires a modification of the interface to lttng-agent. That is not available yet. For the terminology (stop, pause, destroy, etc..), we agree it's confusing especially if you are familiar with the underlying ltt control commands, but we tried to make it as intuitive as possible... Streaming to the host (writeTraceNetwork) should be working now, I'm not sure what state it was in before you fixed and recompiled it, what did you need to change? I know that it wasn't handling properly high load situations before. Best regards, Patrick On Fri, Oct 7, 2011 at 5:11 PM, Thibault, Daniel < [email protected]> wrote: > I'm trying, without success, to get the Eclipse LTTng LinuxTools to work. > First I'll describe my setup, next the symptoms. > > The traced machine is running Ubuntu 11 32-bits and the tcf agent > (20110811 version) with the liblttng-agent and -client plugins (7a8767c > version). > > The tracing machine is running Ubuntu 10 64-bits, the tcf client (same > version), and Eclipse Indigo 3.7.1 CDT+IC (Indigo Service Release 1 > eclipse-linuxtools-indigo-SR1-incubation-linux-gtk-x86_64) with no special > additions. > > If I use the tcf-client on the tracing machine to talk directly to the > traced machine's tcf agent, I can generate a trace just fine ('tcf > ltt_control setupTrace "kernel" "0" "traceTest"' and all that jazz). > > Now I launch Eclipse (with an 'env > LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH"' command prefix), switch > to the RSE perspective, and create an LTTng connection (you can also get at > LTTng through a TCF connection, although this seems a little iffier). The > Files Root node works, but not the Files Home node, oddly. The Processes > node works. The LTTng Tracing node shows the expected "kernel" provider > with a single "0" target. When I create a trace from the contextual menu of > the target, it sort of works. By this I mean that the newly-created trace > is *not* added to the target node until I force a Refresh from the All > Providers node. And then I must configure the trace a second time: it's the > only way to get at the selection of markers (this double-configuration > requirement is really odd and I hope it'll go away later; note also that it > is strange that one cannot browse to the traced machine's target folder for > trace storage, since said folder is perfectly accessible through the LTTng > connection's Files node). > > If I then push the Start button or choose the trace's contextual menu's > Start option, nothing happens. No error. No trace. > > I know the trace has been sort-of-created, because a separately running > tcf-client sees it added to the 'tcf ltt_control getTraces "kernel" "0"' > query response. I can also tell the trace is in an odd, pathological state, > since setTraceTransport (the command right after the setupTrace) fails with > the same message as when you try it with a trace that has not been set up > yet. > > The only thing I've been able to confirm is that Eclipse will 'Stop' > correctly a trace that has been set up and started by the standalone > tcf-client. (This choice of verbs is really unfortunate: 'Stop' is expected > to be opposed to 'Start', but it is not: 'Pause' is opposed to 'Start'. The > underlying ltt-control command is 'Destroy', but that is also a poor choice > of verb, since the trace is not destroyed but rather "concluded" or some > such. 'Destroy' is too much a cognate of 'Delete'. Ah, the joys of > terminology...) > > What am I doing wrong, and how can I get a diagnosis? > > P.S.: Why is it eclipse can't tell whether a trace is running or not? > Can't it simply use 'tcf ltt_control getActiveTraces'? > > Another thing that puzzles me is that I had to fix and recompile the > liblttng-agent and -client plugins in order to get writeTraceNetwork to > work. Since Eclipse offers this option when setting up the trace, > presumably it works and thus it must either a) have found a workaround, or > b) rely on a different implementation of the tcf lttng plugins than the one > downloadable from git.dorsal.polymtl.ca. Please explain. > > Daniel U. Thibault > R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D > Canada - Valcartier (DRDC Valcartier) > Système de systèmes (SdS) / System of Systems (SoS) > Solutions informatiques et expérimentations (SIE) / Computing Solutions and > Experimentations (CSE) > 2459 Boul. Pie XI Nord > Québec, QC G3J 1X5 > CANADA > Vox : (418) 844-4000 x4245 > Fax : (418) 844-4538 > NAC: 918V QSDJ > Gouvernement du Canada / Government of Canada > <http://www.valcartier.drdc-rddc.gc.ca/> > _______________________________________________ > linuxtools-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev >
_______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
