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
