[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[linuxtools-dev] Trying to get the eclipse linuxtools to work
|
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/>
