| Summary: | [LTTng] open trace of selectively imported trace files will crash the workbench | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Yufen Kuo <ykuo> | ||||
| Component: | LinuxTools | Assignee: | Francois Chouinard <fchouinard> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Francois Chouinard <fchouinard> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | patrick.tasse | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 203461 [details]
sample trace files to show the crash
(In reply to comment #0) > Steps to Reproduce: > 1. Download the sample trace files from the attachment > 2 [details]. Create a new LTTng project Not sure why [details] got inserted on step 2, it should be attachment 203461 [details]. I think there are 2 issues here. 1. If we expect users always import all the trace files, in the import window it should not give user a chance to selectively select the files they want to import. 2. if in the native library level, there are errors, it should get properly check for and recover from possible exceptions that have occurred in the method execution. > I think there are 2 issues here. > > 1. If we expect users always import all the trace files, in the import window > it should not give user a chance to selectively select the files they want to > import. LTTng traces are not single files but sets of files stored under a directory. So we are expecting the user to select the directory itself in the left pane of the import dialog. Maybe it could be spelled out more clearly in in the LTTng User Guide. The current dialog performs minimal validation that we are dealing with an LTTng trace but it seems that the test is incomplete (we check that metadata_0 is present and that the version reported is supported). In your use case, well, the test passed... You are right that it is misleading to give the user the possibility to deselect individual files. We are working on a replacement dialog where the user won't have a chance to experiment with Murphy's Law. It should become available with Linux Tools 0.9 (end of October, beginning of November). > 2. if in the native library level, there are errors, it should get properly > check for and recover from possible exceptions that have occurred in the method > execution. The SIGSEVs are produced by the native library over which we have no control other than suggestion (LTTng is a distinct open source project maintained by another organization). Our scope is to bring it to Eclipse and re-using their native parsing library was a time-saver for us. Unfortunately, the lib doesn't provide hooks to catch exceptions and deal with them in Eclipse. Very little is being done today by the LTTng gang on these native libraries because they are focusing LTTng 2.0 which will have a brand new trace format and parser based on CTF (Common Trace Format). On our side, we are taking this opportunity to develop a full EPL Java implementation of the parser to free the Eclipse project from these native libraries (which will become legacy very soon). The new parser won't be available before end-of-year. I can ask for API extensions on the legacy stuff to handle exceptions in Eclipse but don't hold your breath. Best Regards, /fc I've checked with the LTTng people and they don't seem to have a strong will to improve the legacy native libraries and provide an API to handle exceptions. (In reply to comment #4) > I've checked with the LTTng people and they don't seem to have a strong will to > improve the legacy native libraries and provide an API to handle exceptions. Thanks for letting us know. Legacy LTTng 0.x feature is being removed in 2.0. |
Build Identifier: I20110613-1736 If during import, not all of the trace files are selected to be imported, later on when opening the trace, it will crash the workbench with Segmentation fault. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb762eb90 (LWP 16023)] 0x4ff73590 in Java_org_eclipse_linuxtools_lttng_jni_JniEvent_ltt_1positionToFirstEvent (env=0x9531920, jobj=0xb762cf34, tracefile_ptr=159463696) at jni_interface.c:676 676 int returnedValue = ltt_tracefile_seek_time(tracefilePtr, ((struct LttTrace)*(tracefilePtr->trace)).start_time_from_tsc); (gdb) bt #0 0x4ff73590 in Java_org_eclipse_linuxtools_lttng_jni_JniEvent_ltt_1positionToFirstEvent (env=0x9531920, jobj=0xb762cf34, tracefile_ptr=159463696) at jni_interface.c:676 #1 0x50086a78 in Java_org_eclipse_linuxtools_lttng_jni_JniEvent_ltt_1positionToFirstEvent (env=0x9531920, jobj=0xb762cf34, lib_id=0, tracefile_ptr=159463696) at lttvtraceread_loader.c:458 #2 0xb503aaf3 in ?? () #3 0x09531920 in ?? () #4 0xb762cf34 in ?? () #5 0x00000000 in ?? () (gdb) quit Reproducible: Always Steps to Reproduce: 1. Download the sample trace files from the attachment 2. Create a new LTTng project 3. Import the sample trace files from step #1, in the Import dialog, do not select all the files from mphtrace2 directory. Only select the following: a. all the files ends with _3 b. all the metadata_* files 4. finish importing, import should be successful 5. double click on mphtrace2 from Traces folder in the project will crash the workbench