Community
Participate
Working Groups
Build Identifier: Eclipse 3.6.1 with latest linuxtools from SVN trunk The GCov plugin uses the "strings" tool to extract *.gcda filepaths from an associated binary file. This works most of the time, but sometimes the filepath is preceded by a number of random printable characters. The executable generates the correct .gcda files, but the GCov plugin attempts to open a file which does not exist. Example output from "strings | grep gcda" which would trigger the problem: /var/local/build/file1.gcda /var/local/build/file2.gcda /var/local/build/subdir1/file3.gcda ?/var/local/build/subdir1/file4.gcda /var/local/build/subdir2/file5.gcda $@/var/local/build/subdir2/file6.gcda There is no guarantee that a string constant stored in a binary will be preceded by a non-printable byte. Reproducible: Sometimes Steps to Reproduce: 1. Build a CDT project containing multiple source files with -fprofile-arcs -ftest-coverage 2. Execute the binary 3. Double click on one of the resulting .gcda files 4. Choose the "Show coverage for the whole selected binary file." option in the resulting Open Coverage Results dialog 5. Observe the Gcov Parsing Error message box: "An error has occured when parsing the coverage data files : $@/var/local/build/subdir2/file6.gcda"
Created attachment 182816 [details] CovManager.java.patch This patch provides a workaround for the reported issue in the majority of cases. There is still a possibility of triggering the issue if the random printable characters retrieved using the "strings" tool look like an initial path segment. A better technique for determining the location of *.gcda files is desirable.
Hi, Thanks for the bug report and the patch. I've integrated it in trunk (revision 26996). I agree that a better technique for determining the location of *.gcda files is desirable. I mark this bug fixed - but feel free to re-open this bug if needed
John, can you verify this with what will become our Indigo release? You can install it from a few different p2 repositories: http://download.eclipse.org/technology/linuxtools/updates-nightly/ or http://download.eclipse.org/technology/linuxtools/update-indigo or http://download.eclipse.org/releases/staging/ You'll need an Indigo base Eclipse. You could start with the SDK: http://download.eclipse.org/eclipse/downloads/drops/S-3.7RC2-201105191138/index.php Thanks.
(In reply to comment #3) > John, can you verify this with what will become our Indigo release? I can confirm that the fix is still working with Eclipse 3.7RC3 and latest LinuxTools installed via staging update site.
Thanks, John!
