Hi Daniel, Are you using the latest lttng-agent code (dated 2011-08-12)? This one has a fix for corrupted traces when streaming through the network in overload conditions. And it is very possible that the kernel traces produce more events than the network connection can handle. Even without corruption, you could expect a lot of missing events.
If the traces are corrupt, this can cause the libtraceread C library to have a segmentation fault. Unfortunately we can't catch that in the Eclipse java code, so the whole Eclipse dies, as you have noticed. It should leave a log in your Eclipse directory called hs_err_pid*.log. We sometimes can figure out where it crashes in the C library. It might not be the type of markers to be disabled that makes a difference, but rather the fact that those markers generate a high load of events. I don't think you should try importing a trace without its metadata. It's normal if that fails! Best regards, Patrick On Fri, Oct 14, 2011 at 5:28 PM, Thibault, Daniel < [email protected]> wrote: > New problem. > > I've tried various combinations of traces between two machines, using > writeTraceLocal and writeTraceNetwork. All of the network traces, when > imported into LTTV or the Eclipse LTTng perspective, cause the viewer to > crash without any warning. Eclipse's log(s) is(are) empty, it just detects > "The workspace exited with unsaved changes in the previous session; > refreshing workspace to recover changes" when relaunched. I strongly > suspect some kind of corruption of traces done in network mode, but I must > also protest the very poor exception control that these tests reveal. > > Subsets of the network traces can be imported and viewed as long as the > following sub-traces are left out: fs, kernel, mm, net, pm, rcu, and > vm_state. The remaining ones (block, fd_state, global_state, ipc, > irq_state, jbd2, kprobe_state, module_state, netif_state, softirq_state, > swap_state, syscall_state, task_state, userspace) appear fine. The pm > sub-trace crashes Eclipse's LTTng viewer for one trace but not the other > (the two traces are of different machines). > > A (likely unrelated) problem is that if I try to import a "safe" > sub-trace alone (without the metadata), I get an alert > "Unrecognized/unsupported trace version: Library reported trace version > 200.121 [...]". > > Should I file a bug report (or two) and upload one of the offending > traces as a bug attachment? Anything else I can try? Any other way of > validating the trace file contents? > > 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
