Re: [linuxtools-dev] Trying to get the eclipse linuxtools to work

[Patrick Tasse <patrick.tasse@xxxxxxxxx>]

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 <Daniel.Thibault@xxxxxxxxxxxxxxx> 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
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev