tag | cba235a8861aafb2b1dd24d86f26d2cdf428b465 | |
---|---|---|
tagger | Bernd Hufmann <Bernd.Hufmann@ericsson.com> | Fri Oct 02 08:10:41 2015 -0400 |
object | 9dd8df2f7d92d6c4a7e748b5db4c3c773322b77b |
Trace Compass 1.1.0 release
commit | 9dd8df2f7d92d6c4a7e748b5db4c3c773322b77b | [log] [tgz] |
---|---|---|
author | Marc-Andre Laperle <marc-andre.laperle@ericsson.com> | Mon Sep 07 15:15:58 2015 -0400 |
committer | Marc-Andre Laperle <marc-andre.laperle@ericsson.com> | Fri Sep 11 10:44:42 2015 -0400 |
tree | 953cab1e31855fa869c75088eea8f6013fb5c9f4 | |
parent | 9b7c916240fcd14116c0ab88a04548370c379259 [diff] |
ctf: Fix unreliable handling of invalid location This could lead to bad seeks when opening experiments (bug 476816). In experiments, it is often the case (expected) that a seek to a location will result to an invalid location for one of the traces in the experiment. There are issues with the handling of seeking to an invalid location (CtfLocation.INVALID_LOCATION) 1. In one spot, == is used instead of .equals which means that a location read from the index is not considered invalid, but rather, it seeks to an offset of 0. 2. Even if the location is properly considered invalid (== fixed), the code relies on the "last packet end time" to seek past the end of the trace which then make the context location become invalid. This works correctly when the trace was fully read the first time but the "last packet end time" is not necessarily the end of the trace when it is opened a second time. Instead, we can explicitly check for CtfLocation.INVALID_LOCATION in CtfTmfContext.setLocation and CtfIterator.seek to make sure no bad seeks occur. Bug: 476816 Change-Id: I4c74259ae3b67fb22cae302f2d5f09f1adda51f0 Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com> Reviewed-on: https://git.eclipse.org/r/55429 Reviewed-by: Hudson CI Reviewed-on: https://git.eclipse.org/r/55700 Reviewed-by: Bernd Hufmann <bernd.hufmann@ericsson.com> Tested-by: Bernd Hufmann <bernd.hufmann@ericsson.com>
This source tree contains the source code for the Trace Compass plugins for Eclipse.
The plugins are categorized as follows:
analysis/ | Generic extensions to the base framework btf/ | Best Trace Format (BTF) integration common/ | Generic utilities that can be used by other plugins ctf/ | Common Trace Format (CTF) reader library doc/ | Documentation and code examples gdbtrace/ | Support for reading and viewing GDB traces lttng/ | LTTng integration pcap/ | libpcap integration rcp/ | Code specific to the RCP version releng/ | Releng-related plugins statesystem/ | State System library tmf/ | Core framework
See the components.svg
file for a diagram showing the dependencies between the different components.
To set up the environment to build Trace Compass from within Eclipse, see this wiki page: http://wiki.eclipse.org/Trace_Compass/Development_Environment_Setup
To build the plugins manually using Maven, simply run the following command from the top-level directory:
mvn clean install
The default command will compile and run the unit tests. Running the tests can take some time, to skip them you can append -Dmaven.test.skip=true
to the mvn
command:
mvn clean install -Dmaven.test.skip=true
The RCP is not built by default, to build it you need to add -Pbuild-rcp
to the mvn
command:
mvn clean install -Pbuild-rcp -Dmaven.test.skip=true
This will build the RCP for all supported architectures. The resulting archives will be placed in rcp/org.eclipse.tracecompass.rcp.product/target/products
.
These commands will also build the p2 update site, which will be placed in releng/org.eclipse.tracecompass.releng-site/target/repository
.
The following Maven profiles, and their corresponding properties, are defined in the build system. You can set them by using -P[profile name]
and -D[property name]=[value]
in mvn
commands.
-Pctf-grammar
Re-compiles the CTF grammar files. This should be enabled if you modify the .g
files in the ctf.parser
plugin.
-Pbuild-rcp
Builds the RCP archives. Refer to the previous section for details.
-Pdeploy-rcp
Mainly for use on build servers. Copies the generated RCP archives, as well as the RCP-specific update site, to the paths specified by -DrcpDestination=/absolute/path/to/destination
and -DrcpSiteDestination=/absolute/path/to/destination
, respectively. Must be used with -Pbuild-rcp
!
-Pdeploy-update-site
Mainly for use on build servers. Copies the standard update site (for the Eclipse plugin installation) to the destination specified by -DsiteDestination=/absolute/path/to/destination
.
-Psign-update-site
Mainly for use on build servers. Signs all the generated update sites using the Eclipse signing server.
-Pdeploy-doc
Mainly for use on build servers. Copies the generated HTML documentation to the destination specified by -DdocDestination=/absolute/path/to/destination
. Some directories may need to already exist at the destination (or Maven will throw related errors).