linux-test-project / lcov Goto Github PK
View Code? Open in Web Editor NEWLCOV
License: GNU General Public License v2.0
LCOV
License: GNU General Public License v2.0
------------------------------------------------- - README file for the LTP GCOV extension (LCOV) - - Last changes: 2024-03-21 ------------------------------------------------- Description ----------- LCOV is an extension of GCOV, a GNU tool which provides information about what parts of a program are actually executed (i.e. "covered") while running a particular test case. The extension consists of a set of Perl scripts which build on the textual GCOV output to implement the following enhanced functionality: * HTML based output: coverage rates are additionally indicated using bar graphs and specific colors. * Support for large projects: overview pages allow quick browsing of coverage data by providing a hierarchical directory structure view, a flat list of all source files in the project, or a three-level detail view: directory, file and source code view. LCOV was initially designed to support Linux kernel coverage measurements, but works as well for coverage measurements on standard user space applications. LCOV supports differential coverage, as well as date- and owner-binning. See: https://arxiv.org/abs/2008.07947 or https://ieeexplore.ieee.org/document/9438597 for a detailed explanation of the concepts and several possible use models. A video presentation of the basic ideas can be found at http://doi.org/10.5281/zenodo.4653252 In addition, several other features and capabilities have been added. See section 6, below, for a brief description - and also see the man pages and the test cases. Further README contents ----------------------- 1. Included files 2. Installing LCOV 3. Dependencies 4. An example of how to access kernel coverage data 5. An example of how to access coverage data for a user space program 6. New features in lcov 2.0 7. Questions and Comments 8. Filing a new issue 1. Important files ------------------ README - This README file CHANGES - List of changes between releases bin/lcov - Tool for capturing LCOV coverage data bin/genhtml - Tool for creating HTML output from LCOV data bin/gendesc - Tool for creating description files as used by genhtml bin/perl2lcov - Tool to translate Perl Devel::Cover data to lcov format bin/py2lcov - Tool to translate Python Coverage.py to lcov format bin/xml2lcov - Tool to translate Cobertura-like XML coverage data to lcov format bin/geninfo - Internal tool (creates LCOV data files) bin/genpng - Internal tool (creates png overviews of source files) man - Directory containing man pages for included tools example - Directory containing an example to demonstrate LCOV lcovrc - LCOV configuration file Makefile - Makefile providing 'install' and 'uninstall' targets 2. Installing LCOV ------------------ The LCOV package is available as either RPM or tarball from: https://github.com/linux-test-project/lcov/releases To install the tarball, unpack it to a directory and run: make install Use Git for the most recent (but possibly unstable) version: git clone https://github.com/linux-test-project/lcov.git Change to the resulting lcov directory and type: make install The default install location is /usr/local. Note that you may need to have superuser permissions to write into system directories. To install in a different location - for example, your home directory, run: make PREFIX=$HOME/my_lcov install your PREFIX should be an absolute path. To run the LCOV regression test suite on your installation: $ cp -r $LCOV_HOME/share/test path/to/myTestDir $ cd path/to/myTestDir $ make [COVERAGE=1] If desired, you can collect coverage data for the LCOV module by setting the COVERAGE makefile variable. Note that the Devel::Cover package must be installed if COVERAGE is enabled or if you want to use the perl2lcov utility. To view the collected coverage information, point your browser to .../lcov_coverage/index.html after running the tests. Note that the testcases are intended to test LCOV functionality and not to be easily readable tutorial examples. 3. Dependencies: ---------------- The lcov module is implemented primarily in Perl - and requires both a moderately up-to-date Perl installation and multiple Perl packages. These perl packages include: - Capture::Tiny - DateTime - Devel::Cover - Digest::MD5 - File::Spec - at least one flavor of JSON module. In order of performance/preference: - JSON::XS - Cpanel::JSON::XS - JSON::PP - JSON - Memory::Process - Module::Load::Conditional - Scalar::Util - Time::HiRes If your system is missing any of these, then you may be able to install them via: $ perl -MCPAN -e 'install(<packageName>)' You will very likely need superuser access to be able to install Perl modules. Some of the applications provided with the lcov module are written in Python - and may require additional Python packages. In particular, 'xlsxwriter' is required in order to generate any of the spreadsheet reports. To measure Python code coverage, users will need Python packages: - Coverage.py In addition, contributors will need: - perltidy Your platform may support other mechanisms to install and/or update required packages. 4. An example of how to access Linux kernel coverage data --------------------------------------------------------- Requirements: Follow the Linux kernel coverage setup instructions at: https://docs.kernel.org/dev-tools/gcov.html As root, do the following: a) Resetting counters lcov --zerocounters b) Capturing the current coverage state to a file lcov --capture --output-file kernel.info c) Getting HTML output genhtml kernel.info Point the web browser of your choice to the resulting index.html file. 5. An example of how to access coverage data for a user space program --------------------------------------------------------------------- a) Capture current coverage state to a file: i) C/C++ code: Compile your program using the '--coverage' GCC or LLVM option. During linking, make sure to specify '--coverage': $ gcc -o myTest --coverage simple.c OR $ gcc -c file1.c file2.c ... --coverage $ gcc -o myOtherTest --coverage file1.o file2.o .... Run your testcase at least once: $ path/to/my/testcase/myTest Capture the current coverage state to a file: $ lcov --directory path/to/my/testcase --capture --output-file app.info Note that runtime coverage data exists only after the application has been started and stopped at least once. Otherwise, no data will be found and lcov will abort with an error mentioning that there are no data/.gcda files. The coverage runtime emits data (the .gcda files) in an atexit callback. If your application exits abnormally or crashes before the callback is executed, then no coverage data will be available. For further information on the gcc profiling mechanism, please consult the gcov man page. See 'man lcov' for more information - especially if your build/test environment is not trivial. ii) Python code: - install the Coverage.py module - execute your testcase to produce python coverage data: $ COVERAGE_FILE=./pycov.dat coverage run --append --branch \ myPythonScript [my script args] - translate Python coverage data to LCOV format: $ py2lcov -o pycov.info [py2lcov_options] pycov.dat [x.dat]+ See 'py2lcov --help' and the Coverage.py documentation for more information. iii) Perl code: - install the Devel::Cover module - execute your testcase to produce perl coverage data: $ perl -MDevel::Cover=-db,perlcov_db,-coverage,statement,branch,condition,subroutine,-silent,1 myPerlTest.pl [my script args] - translate Perl coverage data to LCOV format: $ perl2lcov --output perlcov.info perlcov_db [perl2lcov options] See 'perl2lcov --help' and the Devel::Cover documentation for more information. iv) XML data (for example, generated by Cobertura): - translate XM coverage data to LCOV format: $ xml2lcov --output myData.info coverage.xml [xml2lcov options] See 'xml2lcov --help' and the Cobertura documentation for more information. b) Generate an HTML coverage report: Generate an HTML report, combining all of your LCOV data files: $ genhtml -o html_report app.info pycov.info perlcov.info Point the web browser of your choice to the resulting file: html_report/index.html. See 'man genhtml' for more details. c) Generate a differential coverage report: See the example in .../example (run "make test_differential") as well as the examples in .../tests/gendiffcov. 6. New features: ---------------- New features and capabilities fall into 7 major categories: a) Categorization This refers primarily to differential coverage categorization as well as date- and owner-binning. See https://arxiv.org/abs/2008.07947 or https://ieeexplore.ieee.org/document/9438597 for a detailed description of the concepts. Differential categorization and binning are orthogonal in the sense that you can generate differential report without binning as well as 'vanilla' coverage reports with binning. See the above papers and the genhtml man page for details. Related options: --baseline-file, --diff-file, --annotate-script, --select-script --date-bins, --new-file-as-baseline, --elide-path-mismatch b) Error handling A generic - but very simple - error handler has been added to the lcov tool suite. The error handler is used to report exceptions, and provides a mechanism for the user to ignore the particular message if desired. See the genhtml/lcov/geninfo man pages for details. Note that some errors are unrecoverable - and cannot be suppressed or ignored. Related options: --ignore-error, --keep-going c) Navigation and display: Navigation aids such as hyperlinks to the first uncovered region, to the next uncovered region, etc. have been implemented. Similarly, new tables, new columns, and new links between tables enable the user to identify the author of particular code (covered or not covered), as well as the time period when the code was written. Collectively, these features help the user to quickly identify the cause of code coverage issues, and to then decide what to do. An option to generate a 'hierarchical' coverage report (which follows the source code directory structure) or 'flat' (all files in top level of two-level report) as well as various other small features (tooltip popups, user-specified HTML header, footer, and table labels, etc.) are also available. See the genhtml man page for some details, as well as the 'gendiffcov/simple' testcases for some examples. Related options: --baseline-title, --baseline-date, --current-date, --flat, --hierarchical, --show-owners, --show-noncode, --show-navigation, --show-proportion, --suppress-aliases d) Data manipulation Filters are used to suppress or remove certain coverage artifacts - for example, branches generated by the compiler (e.g., for exception handling). These artifacts can overwhelm the user code and obscure coverage features that are interesting to the user. Other options are used to focus on or to exclude certain sections of code, as well as to do regexp replacement of file names - possibly using case-insensitive comparison. (Path munging is useful primarily when the build structure does not exactly match the layout in your revision control system; this is common in large projects with reusable components.) During coverage data capture, the --build-directory option can be used to specify a search path, to find the .gcno (compile-time coverage data) file corresponding to a particular .gcda runtime coverage data) file. Similarly, the --source-directory pption can be used to specify a search path for source files. See the lcov/geninfo/genhtml man pages for a detailed description of the available filters and manipulation features. Related options: --include, --exclude, --erase-functions, --omit-lines, --substitute, --filter --build-directory --source-directory e) Callbacks/customization The user can supply callbacks which are used to: i) interface with the revision control system Sample scripts: - Perforce: see 'p4diff' and 'p4annotate' - Git: see 'gitdiff' and 'gitblame' ii) verify that source code versions are compatible, and Sample scripts: see 'get_signature', 'getp4version' and 'gitversion' iii) enforce a desired code coverage criteria Sample script: criteria iv) find source files in more complicated environments - where simple substitutions become complicated or unweildy. v) select a subset of coverage data to display - e.g., to use in a code review which wants to concentrate on only the changes caused by a particular commit or range of commits. The callback may be any desired script or executable - but there may be performance advantages if it is written as a Perl module. See the genhtml/lcov/geninfo man pages for details. Note that the various sample scripts are found in the source code 'scripts' directory, but are installed in the $LCOV_HOME/share/lcov/support-scripts directory of the release. Related options: --annotate-script, --criteria-script, --version-script --resolve-script --select-script f) Performance lcov/genhtml/geninfo have been refactored to parallelize computation across multiple cores, if requested. In general, this provides speedup that is nearly linear in the number of cores. There is also an option to throttle parallelism to not exceed peak memory consumption constraints, as well as options to enable simple profile data collection - so you can see where time is going and thus to hint at potential optimizations. The 'spreadsheet.py' script can be used to view generated profile data. There are several configuration file options which can be used to tweak certain parallelization parameters to optimize performance for your environment in cases that the default behaviour is suboptimal. See the lcovrc man page for more information. See the genhtml/lcov/geninfo man pages for details Related options: --parallel, --memory, --profile g) Language support Added 'py2lcov', 'perl2lcov' and 'xml2lcov' scripts. - py2lcov: translates python Coverage.py XML data to lcov format. See the Coverage.py documentation at https://coverage.readthedocs.io, as well as ".../py2lcov --help" - perl2lcov translates Perl Devel::Cover data to lcov format. See the Devel::Cover documentation at https://metacpan.org/pod/Devel::Cover to find out how to generate coverage data for Perl code. See "perl2lcov --help" for brief instructions on how to use the translator. Note that perl2lcov uses a similar set of command line and config file options as lcov, genhtml, and geninfo. - xml2lcov translates XML coverage data to lcov format. The XML data may come from Cobertura or similar tools. See "xml2lcov --help" fir brief instructions on how to use the translator. See the Coburtura documention for directions on how to generate XML data. Other languages can be integrated using a similar approach. In general, the new features and options are implemented uniformly in lcov, genhtml, and geninfo. Most of the features can be enabled/disabled using either command line options or by setting defaults in your 'lcovrc' file. See the lcovrc man page for details. 7. Questions and comments ------------------------- See the included man pages for more information on how to use the LCOV tools. In case of further questions, feel free to open a new issue using the issue tracker on the LCOV code repository site at: https://github.com/linux-test-project/lcov 8. Filing a new issue --------------------- Before filing a new issue - and if you are using an LCOV release (as opposed to using a clone of the github repo) - please verify whether the issue is still present in the LCOV master version. See section 2, above for directions on how to clone and install the most up-to-date LCOV version. If possible, please include a testcase which illustrates the problem when you file an issue. Please describe your environment (platform, compiler, perl, and python versions, etc.). Please include a detailed description of the issue: what you were trying to do (your goal - not the mechanics of your procedure), what you did (the mechanics of your procedure), the result you wanted to see vs. what actually happened. Depending on the issue, your testcase may need to include source code and compile/link command lines, directions for how to run your example, the command lines used to capture and generate your lcov reports, etc. In other cases, the captured '.info' files may be sufficient to reproduce the issue. When in doubt: more is better than less. If you cannot include a testcase - e.g., because you feel that it is senstitive or proprietary - then your detailed description is even more important. Note that, without an example, it may be difficult or impossible to diagnose or fix the problem. Bear in mind that you are asking for help from volunteers. Your priority might not be their priority. Civility, consideration and politeness go a long way. Please check back and to verify the fix and close the issue once it has been addressed. Again: remember that you are asking for help from volunteers. Make sure that you are doing your part.
Per the Filesystem Hierarchy Standard, Version 2.2 ⟨http://www.pathname.com/fhs/), programs that are local to the site are typically installed to /usr/local/ . However, the Makefile installs by default to /usr/bin and /usr/share/doc . This means that by default, building from source will not "play nice" with distribution packages of lcov.
Changing the default install prefix to /usr/local will help to alleviate this problem and make installing from source friendlier to novices who might not realize that this could mess with their distribution's installed packages.
Using the filter (-r) of Lcov 1.13 is not working like Lcov 1.12 or Lcov 1.10 (tested just those two).
I ran:
lcov --no-external --base-directory $PWD --directory $PWD --rc lcov_branch_coverage=1 -c -o coverage.info
followed by:
lcov -r coverage.info /build/* --rc lcov_branch_coverage=1 -o coverage.info
This is what I get when I ran the filter command above with lcov 1.13:
Reading tracefile coverage.info
Deleted 0 files
Writing data to coverage.info
Summary coverage rate:
lines......: 68.2% (2022 of 2965 lines)
functions..: 72.9% (976 of 1338 functions)
branches...: 31.7% (2021 of 6383 branches)
This is what I get when I ran the same command with lcov 1.12 or 1.10:
Reading tracefile /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/lcov/coverage.info
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/dependencies/service.api-1.0-SNAPSHOT/include/logservice/ILogService.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/dependencies/service.utilities-1.0-SNAPSHOT/include/threading/Condition.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/dependencies/service.utilities-1.0-SNAPSHOT/include/threading/IThreadable.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/dependencies/service.utilities-1.0-SNAPSHOT/include/threading/Mutex.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/dependencies/service.utilities-1.0-SNAPSHOT/include/threading/ThreadPool.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/dependencies/service.utilities-1.0-SNAPSHOT/include/threading/Threader.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/testDependencies/gtest-1.8/include/gtest/gtest-message.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/testDependencies/gtest-1.8/include/gtest/gtest.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/testDependencies/gtest-1.8/include/gtest/internal/gtest-internal.h
Removing /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/testDependencies/gtest-1.8/include/gtest/internal/gtest-port.h
Deleted 10 files
Writing data to /home/vnwachukwu/pipeline-test-cpp/com.ngc.blocs.cpp.service.log.impl.logservice/build/lcov/coverage.info
Summary coverage rate:
lines......: 83.4% (717 of 860 lines)
functions..: 87.3% (145 of 166 functions)
branches...: 31.7% (1032 of 3251 branches)
Please consider publishing your release tarballs on github (in addition or in replacement of SF.net). It's as simple as:
You can insert any tarball here, including the make dist
product release.
Thanks!
+ /usr/bin/make -O -j4 test -j1 Creating coverage files (2 tests, 5 source files) Source tree ......... done (950 lines, 50 functions, 3428 branches) Full coverage ....... done Target coverage ..... done Partial coverage .... done Zero coverage ....... done Starting tests genhtml_output_zero .......... [pass] (time 0.3s, mem 12.4MB) genhtml_output_full .......... [pass] (time 0.3s, mem 12.3MB) genhtml_output_target ........ [pass] (time 0.3s, mem 12.5MB) genhtml_output_part1 ......... [pass] (time 0.3s, mem 12.4MB) genhtml_output_part2 ......... [pass] (time 0.3s, mem 12.4MB) genhtml_output_combined ...... [pass] (time 0.8s, mem 13.4MB) lcov_add_zero ................ [pass] (time 0.3s, mem 12.2MB) lcov_add_zero2 ............... [pass] (time 0.5s, mem 13.3MB) lcov_add_full ................ [pass] (time 0.3s, mem 12.2MB) lcov_add_full2 ............... [pass] (time 0.5s, mem 13.4MB) lcov_add_part ................ [pass] (time 0.3s, mem 12.3MB) lcov_add_part2 ............... [pass] (time 0.5s, mem 13.5MB) lcov_add_concatenated4 ....... [pass] (time 0.5s, mem 12.7MB) lcov_diff_apply .............. [fail] (time 0.6s, mem 17.7MB) COMMAND ....: "./diff_test" OUTPUT .....: Capturing coverage data from . Found gcov version: 9.0.1 Scanning . for .gcda files ... geninfo: WARNING: /home/tkloczko/rpmbuild/BUILD/lcov-1.14/test/lcov_diff/old/prog.gcno: Overlong record at end of file! Found 1 data files in . Processing prog.gcda geninfo: WARNING: cannot find an entry for prog.c##9d444dbee7ca7875c029725315296e84.gcov in .gcno file, skipping file! Finished .info-file creation ... Skipping 12 more lines (see /home/tkloczko/rpmbuild/BUILD/lcov-1.14/test/test.log) lcov_version ................. [pass] (time 0.1s, mem 11.7MB) lcov_help .................... [pass] (time 0.1s, mem 11.5MB) lcov_summary_zero ............ [pass] (time 0.2s, mem 12.3MB) lcov_summary_full ............ [pass] (time 0.2s, mem 12.1MB) lcov_summary_target .......... [pass] (time 0.2s, mem 12.3MB) lcov_summary_part1 ........... [pass] (time 0.2s, mem 12.4MB) lcov_summary_part2 ........... [pass] (time 0.2s, mem 12.2MB) lcov_summary_concatenated .... [pass] (time 0.2s, mem 12.4MB) lcov_summary_concatenated2 ... [pass] (time 0.2s, mem 12.4MB) 23 tests executed, 22 passed, 1 failed, 0 skipped (time 7.8s, mem 292.8MB) Result log stored in /home/tkloczko/rpmbuild/BUILD/lcov-1.14/test/test.log make[1]: *** [common.mak:34: exit] Error 1
According to the man page, --show-details should generate a page that discriminates the coverage by test cases. However when I make
in example/
(where multiple test cases and the option in question are used), there is only one page for each source file (such as lcov-1.13/example/output/example/example.c.gcov.frameset.html). The test case is given as "Basic example". There is no "link to a detailed version".
The update to XCode 8.0 seem to brought an issue similar to #10.
The behavior we get is:
$ lcov --capture --no-external --initial --base-directory packages --directory . --output-file ./report.init
Capturing coverage data from .
Scanning . for .bb files ...
geninfo: WARNING: no .bb files found in . - skipping!
Finished .info-file creation
Version of lcov and gcov:
$ gcov --version
Apple LLVM version 8.0.0 (clang-800.0.38)
$ lcov --version
lcov: LCOV version 1.12
lcov -r is taking over an hour on a large project. Algorithm issue since memory usage is only at 2%. Seems to be taking forever on read_info_file() -> br_ivec_push() -> br_ivec_get() . Might be worth rewriting the happy path in C.
Hi, I need to use lcov in a non standard environment where perl interpreter is determined by the environment, and thus the current usage of #!/usr/bin/perl prevents it from working in such environment.
I've prepared a patch with the change, please confirm if it is reasonable and accepted.
Thanks.
following situation has been extracted form real code:
#include <stdlib.h> /* for exit() */
unsigned int UuT(void)
{
unsigned int true_var = 1;
unsigned int false_var = 0;
unsigned int ReturnStatus_t = 0;
if (false_var) {
ReturnStatus_t = 1;
}
else {
if (true_var) {
if (true_var) {
ReturnStatus_t = 0;
}
else {
if (true_var) {
ReturnStatus_t = 0;
}
else {
**/* Following line falsely marked as covered when parameter "--rc lcov_branch_coverage=1" is set */**
ReturnStatus_t = 0;
}
}
}
else {
ReturnStatus_t = 0;
}
}
return (ReturnStatus_t);
}
int main(int argc, char** argv) {
UuT();
return 0;
}
This c-code compiled with an old as well as the current cygwin package (gcov versions 4.8.2 and 6.3.0) causes a faulty count of the line - marked with a comment - during line coverage.
lcov and genhtml has been executed with to following script:
#!/bin/bash
[ "$COMSPEC" ] && set -o igncr; # Ignore CR if on Windows system
./Debug/LCOV_Test.exe
lcov -c -d Debug -o LCOV_Test_wb.info --rc lcov_branch_coverage=1 --checksum
genhtml LCOV_Test_wb.info -o ./lcov_wb
lcov -c -d Debug -o LCOV_Test_wob.info --rc lcov_branch_coverage=0 --checksum
genhtml LCOV_Test_wob.info -o ./lcov_wob
The version with the setting --rc lcov_branch_coverage=0 doesn't count the marked line as executed correctly.
The version with the setting --rc lcov_branch_coverage=1 count the marked line as executed falsely.
Used lcov version was 1.13.
For me it looks like a bug and I hope the effect is reproducible.
Best regards
MMelzig
Hello,
it seems that lcov/geninfo uses directory specified by --base-directory
parameter for temporary files. This breaks parallel execution of multiple lcov instances on the same base directory, or of base-directory
is read-only for any reason.
Parallel execution might sound weird at first, but it makes sense for programs which are executed in parallel and test coverage needs to be combined from all individual runs.
I have hundreds of .gcda
and .gcno
trees from the same program (which was run in parallel and gcda files redirected elsewhere) and now I'm attempting to create individual .info
files for each run and then combine all .info
files into the final info file used for genhtml
.
While doing this, I attempted to speed up the process by executing lcov in parallel:
lcov -q --base-directory '$(TOPSRCDIR)' --no-external --capture -d daemon -o tempfile$(n).info
but lcov processing fails with following errors:
geninfo: WARNING: cannot find an entry for #usr#include#bits#stdio2.h.gcov in .gcno file, skipping file!
Further inspection of strace output showed that lcov creates these files in base-directory
.
Please consider creating temporary files outside of temporary directory.
Thank you!
Hi,
so I know that lcov -c --initial does not support branch coverage. But is there a way to not loose the branch coverage data if we combine the initial tracefile with a tracefile containing branch coverage?
Thanks.
I believe lcov
uses gcc version to decide what kind of files to be scanned, but in MacOS the alias of gcc
is clang
, which causes lcov
expects .da instead of .gcda. But the default type of files created by clang
is .gcda. So I think it needed to be improved.
Hi,
with:
lcov: LCOV version 1.11 pre (CVS 1.98)
launching:
lcov --rc lcov_branch_coverage=1 --capture --initial -d
we recently encountered these errors:
lcov: Use of each() on hash after insertion without resetting hash iterator results in undefined behavior, Perl interpreter: 0xcad010 at /usr/bin/lcov line 232.
geninfo: Use of each() on hash after insertion without resetting hash iterator results in undefined behavior, Perl interpreter: 0x1b6f010 at /usr/bin/geninfo line 284.
Thanks,
Eric
Need a point release so homebrew can pull the fix for XCode8.
Hi,
I'm generating a code coverage report in Ubuntu 16. The -a
/ --add-tracefile
flag fails when lcov is installed via:
sudo apt-get install lcov
Instead when installing lcov v1.12 from source this problem does not arise.
This is follow up of #38.
For GCC 9.1 I'm planning to come up with JSON format of the intermediate representation.
Feel free to comment my patch request:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01628.html
lcov is able to show:
I understand function coverage to which percentage functions are entered and thereby tested.
From my point of view it is very helpful to be able to measure to which percentage calls to function(s) has been tested. The call coverage.
An example for the difference and for the need of this metric. Let's assume we have one function A, which calls another function B. To know that function B is entered (at least once = function coverage) is one side. But when the function B is called from 3 different locations in function A and in each of these calls a mistake can be made e.g. with parameter order there is an additional need to know whether each of the existing calls are applied = Call coverage.
Best regards
MMelzig
If a *.c file only contains some global constant the gcno file produced by the --coverage option is not readable by lcov
eg using gcc-8.0.1-0.16.fc29.x86_64 (forthcoming GCC 8 release currently in Fedora 29 rawhide)
[build@localhost tmp]$ cat t.c
const int a = 5;
[build@localhost tmp]$ gcc -Wall -Wextra -Werror -c ./t.c --coverage
[build@localhost tmp]$ lcov --capture --initial --directory .
Capturing coverage data from .
Found gcov version: 8.0.1
Scanning . for .gcno files ...
Found 2 graph files in .
Processing t.gcno
geninfo: ERROR: /tmp/t.gcno: reached unexpected end of file
The same works as expected with gcc-7.3.1-2.fc27.x86_64 on Fedora 27:
[sbose@p50 y]$ cat t.c
const int a = 5;
[sbose@p50 y]$ gcc -Wall -Wextra -Werror --coverage -c t.c
[sbose@p50 y]$ lcov --capture --initial --directory .
Capturing coverage data from .
Found gcov version: 7.3.1
Scanning . for .gcno files ...
Found 1 graph files in .
Processing t.gcno
TN:
Finished .info-file creation
Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=1552042
Hi! First thanks for you maintain lcov, it's really helps a lot!
But here we got a problem. As we have too much files to cover, each time we use lcov run one loop will take 3-5mins. When all put together it takes too much time.
As we only need the percentage, we'v used "--no-source" option in genhtml, but I notices that lcov will search source code each time and there's no option for me to forbid this step. I believe it will help reduce time a lot ,could you help us?
Or there is some other ways for us to reduce time cost?
Thanks!
Hi
Integrated into my objective-c project, generated HTML by calling the function and then displayed in the WebView inside the app.
Can I use it like this?
Hi,
There is an issue introduced in lcov 1.11 that fails on some virtual destructors. Attached below:
[369]/tmp>cat foo.cc
typedef int time_point_t;
class IClock
{
public:
virtual ~IClock () { }
virtual time_point_t Now () = 0;
};
namespace
{
class DefaultClock : public IClock
{
public:
virtual time_point_t Now() // override
{
return 0;
}
} defaultClock;
}
int main()
{
return 0;
}
[370]/tmp>g++ -v
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
[371]/tmp>g++ foo.cc -fprofile-arcs -ftest-coverage
[372]/tmp>a.out
[373]/tmp>lcov --capture --directory . --output foo.info
Capturing coverage data from .
Found gcov version: 4.1.2
Scanning . for .gcda files ...
Found 1 data files in .
Processing foo.gcda
Finished .info-file creation
[374]/tmp>genhtml --legend --demangle-cpp --output-directory html foo.info
Reading data file foo.info
Found 1 entries.
Demangling 10 function names
genhtml: ERROR: Demangled function name (anonymous namespace)::DefaultClock::~DefaultClock() maps to different lines (21 vs 15) in /tmp/foo.cc
[375]/tmp>/opt/lcov-1.10/bin/lcov --capture --directory . --output foo.info
Capturing coverage data from .
Found gcov version: 4.1.2
Scanning . for .gcda files ...
Found 1 data files in .
Processing foo.gcda
Finished .info-file creation
[376]/tmp>/opt/lcov-1.10//bin/genhtml --legend --demangle-cpp --output-directory html foo.info
Reading data file foo.info
Found 1 entries.
No common filename prefix found!
Writing .css and .png files.
Generating output.
Processing file /tmp/foo.cc
Writing directory view page.
Overall coverage rate:
lines......: 80.0% (8 of 10 lines)
functions..: 66.7% (8 of 12 functions)
[377]/tmp>
Using
$ gcov --version
Apple LLVM version 9.0.0 (clang-900.0.38)
Optimized build.
Default target: x86_64-apple-darwin16.7.0
Host CPU: sandybridge
geninfo seems to parse this output in a way that causes lcov to think this the equivalent of an older version of gcov... so it goes looking for .da files
If this is a known problem and someone's working it, cool, but if someone needs it worked I'm happy to try to fix it and contribute a patch.
When generating the HTML output, there’s currently only an anchor at the start of every function. It would be more useful if there was one per line of output, so that (for example) one can link to a specific line which needs looking at from a bug report.
./genreport.sh:14: command not found: Capturing
echo "===== starting ====="
HOME_PATH="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
LCOA_PATH="${HOME_PATH}/lcov/1.13/bin"
OBJS_PATH="${HOME_PATH}/objs"
Consider the following minimal example:
(sample.cxx)
struct V {
~V() {}
};
struct A {
V _v;
};
int main( int argc_, char** ) {
A a;
return 0;
}
Compile with g++ --coverage sample.cxx
, generate coverage report with:
lcov -b . -d . -c -i -o base.info
./a.out
lcov -b . -d . -c -o test.info
lcov -a base.info -a test.info -o coverage.info
genhtml --legend coverage.info -o html
This results in following report:
Line data Source code
1 : struct V {
2 1 : ~V() {}
3 : };
4 :
5 0 : struct A {
6 : V _v;
7 : };
8 :
9 1 : int main( int argc_, char** ) {
10 1 : A a;
11 1 : return 0;
12 : }
13 :
Observe 0
hits reported for struct A
declaration at line 5
.
This problem only manifests on GCC/gcov 8, previous version of GCC/gcov reports no active code at line 5
.
I want to generate a code coverage report for my Qt/C++ project.
I have a short version with a class inheriting QObject:
#include <QObject>
class Baba : public QObject {
Q_OBJECT
public:
Baba();
void mange(int a);
signals:
void pouet();
};
I first add this compilation flag:
QMAKE_CXXFLAGS += --coverage
QMAKE_LFLAGS += --coverage
After executing my tests, I perform the following step:
$ gcov main.cpp
$ lcov --capture --directory . --output-file capture.info
$ lcov --remove capture.info "*Qt*.framework*" "*.h" "*Xcode.app*" "*moc_*" --output-file filtered.info
$ genhtml filtered.info --output-directory out
Unfortunately I still have coverage for the file moc_Baba.cpp
despite I added "*moc_*"
during the remove step.
Am I doing something wrong?
We use lcov with gcc-8 in our bitbucket pipelines, and there seems to be a regression in 9aa0d14 that generates lots of error messages saying geninfo: Use of uninitialized value in hash element at /usr/local/bin/geninfo line 3001.
followed by a single error message at the end saying geninfo: Can't use an undefined value as an ARRAY reference at /usr/local/bin/geninfo line 2889.
.
$ /usr/local/bin/lcov --no-checksum --directory /home/developer/ws/ignition/src/ign-math/build --capture --output-file coverage.info
Capturing coverage data from /home/developer/ws/ignition/src/ign-math/build
Found gcov version: 8.2.0
Scanning /home/developer/ws/ignition/src/ign-math/build for .gcda files ...
Found 46 data files in /home/developer/ws/ignition/src/ign-math/build
Processing test/CMakeFiles/gtest.dir/gtest/src/gtest-all.cc.gcda
geninfo: Use of uninitialized value in hash element at /usr/local/bin/geninfo line 3001.
geninfo: Use of uninitialized value in hash element at /usr/local/bin/geninfo line 3001.
...
geninfo: Use of uninitialized value in hash element at /usr/local/bin/geninfo line 3001.
geninfo: Use of uninitialized value in hash element at /usr/local/bin/geninfo line 3001.
geninfo: Can't use an undefined value as an ARRAY reference at /usr/local/bin/geninfo line 2889.
To demonstrate this, I made a branch that explicitly checks out 1e0df57 (the parent of 9aa0d14), and invokes lcov
without the -q
argument. It works properly and uploads coverage to codecov.
I then made a follow-up commit that checks out 9aa0d14, and it fails with the error message I described above:
I get a warning from perl interpreter for each processed file:
Processing file src/utils/globs.c
genhtml: Negative repeat count does nothing at /usr/bin/genhtml line 3854, <SOURCE_HANDLE> line 162.
It points to the last line of this function:
sub fmt_centered($$)
{
my ($width, $text) = @_;
my $w0 = length($text);
my $w1 = int(($width - $w0) / 2);
my $w2 = $width - $w0 - $w1;
return (" "x$w1).$text.(" "x$w2); # <-- here
}
It happens with genhtml_line_field_width = 8
in configuration file because "Line data"
string has length of 9 in this invocation:
my $line_heading = fmt_centered($line_field_width, "Line data");
It doesn't affect functionality in any way, but clutters the output.
I have created a simple example to illustrate the issue:
test.h
#ifndef TEST_H
#define TEST_H
class TestCoverage{
public:
/*
*
*
*
*/
int a = 5;
int b = 10;
void testfunc();
explicit TestCoverage();
};
#endif // TEST_H
test.cpp
#include "test.h"
#include <iostream>
TestCoverage::TestCoverage()
{
a=15;
b=20;
}
void TestCoverage::testfunc(){
/*
*
* */
std::cout<<"hey";
}
And added a simple test case (which checks nothing) using catch2:
#include "test.h"
#include <catch2/catch.hpp>
TEST_CASE("test", "[whatever]")
{
auto testCoverage = new TestCoverage();
testCoverage->testfunc();
}
Afterwards I generated a code coverage report using lcov and generated html file (I have built it with -O0 flag). Html file shows some strange results: https://i.stack.imgur.com/WxSxe.png
The question is: why lines 11 and 12 are displayed as covered? It looks like they are completely mirroring the class member initialization in the header file (a and b initialization). If I move initialization across the header file - the covered lines in the cpp file also move. Is this a bug in lcov or am I missing something?
In GLib, there are a couple of macros which are used to implement preconditions on user functions, called g_return_if_fail()
, g_return_val_if_fail()
, g_return_if_reached()
, etc. These expand out to an ‘if’ statement with one branch which is expected to always be taken, and the other branch which is expected to never be taken, and which shouldn’t be tested for in test cases because testing the preconditions for every user function would be a waste of time.
It would be nice if lcov supported using LCOV_EXCL_*
inside the macro definitions so that the second branch was ignored in every instance of the macros without having to annotate them all separately.
(This was originally reported as https://sourceforge.net/p/ltp/feature-requests/8/.)
Even when template code is executed the coverage is always zero.
I was trying to figure out why my tool was giving different file lists from lcov on a very large codebase (mozilla-central, if you're wondering). Turns out that one of the .gcno files had source names like
/home/worker/workspace/build/src/modules/woff2/src/././buffer.h--gcov processed this into .../src/buffer.h, but geninfo wasn't finding that in the module, so it was dropping it from the buffer.
It looks like the normalization in solve_relative_path is to blame:
# Remove .
$result =~ s/\/\.\//\//g;
$result =~ s/\/\.$/\//g;
I have built compiler with --enable-coverage which generates the .gcda files in built directory.
After trying to run lcov as
path/to/bin/lcov -c -d path/to/*.gcda/files/ -o info.info
I am getting error as:
Capturing coverage data from . Found gcov version: 6.3.0 Scanning . for .gcda files ... Found 460 data files in . Processing i386.gcda geninfo: ERROR: build/gcc/i386.gcno: could not open file
I tried using the latest cloned repo at github but problem still persists.
The code in geninfo to determine the version of the gcov tool no longer works for LLVM gcov 7.0. It results in the following error:
geninfo: Use of uninitialized value $version_string in substitution (s///) at /usr/local/bin/geninfo line 1914.
geninfo: Use of uninitialized value $version_string in pattern match (m//) at /usr/local/bin/geninfo line 1917.
geninfo: Use of uninitialized value $version_string in pattern match (m//) at /usr/local/bin/geninfo line 1930.
geninfo: Use of uninitialized value $gcov_version_string in pattern match (m//) at /usr/local/bin/geninfo line 3720.
geninfo: Use of uninitialized value $gcov_version_string in pattern match (m//) at /usr/local/bin/geninfo line 3720.
The output of gcov --version
under OS X:
$ gcov --version
Apple LLVM 7.0.0 (clang-700.0.72)
Fedora 30 rawhide has pulled in the last GCC 9.0.0 version and this appears incompatible with lcov
$ echo "const int a = 5; int main(void) { return 1;}" > t.c
$ gcc -Wall -Wextra -Werror ./t.c --coverage
$ ./a.out
Previously with GCC 8 compiled binaries this would work:
$ lcov -t "result" -o ex_test.info -c -d .
Capturing coverage data from .
Found gcov version: 8.2.1
Scanning . for .gcda files ...
Found 1 data files in .
Processing t.gcda
Finished .info-file creation
$ lcov -l ex_test.info
Reading tracefile ex_test.info
|Lines |Functions |Branches
Filename |Rate Num|Rate Num|Rate Num
==================================================
[/home/berrange/src/virt/libvirt-go/]
t.c | 100% 1| 100% 1| - 0
==================================================
Total:| 100% 1| 100% 1| - 0
With GCC 9 compiled binaries it fails
$ ./lcov/bin/lcov -t "result" -o ex_test.info -c -d .
Capturing coverage data from .
Found gcov version: 9.0.0
Scanning . for .gcda files ...
Found 1 data files in .
Processing t.gcda
geninfo: WARNING: /home/berrange/t.gcno: Overlong record at end of file!
geninfo: WARNING: gcov did not create any files for /home/berrange/t.gcda!
Finished .info-file creation
There are some GCC changes that affected coverage data format:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261189
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=264462
The info above is all taken from a Fedora bug report https://bugzilla.redhat.com/show_bug.cgi?id=1668843
When I try to install the current 1.12 RPM package on CentOS 7.2 with sudo yum --nogpgcheck localinstall lcov-1.12-1.noarch.rpm
I get the error file /usr/bin from install of lcov-1.12-1.noarch conflicts with file from package filesystem-3.2-20.el7.x86_64
.
Apparently this is due to an incorrect package definition, where system directories are "owned" by lcov (see e.g. http://unix.stackexchange.com/a/257150).
Please provide an updated RPM package for download.
The output of gcov-8 includes repeated lines for template instantiations. This could be problematic for process_dafile
in geninfo
where $line_number
is incremented for every line.
Lines 1388 to 1394 in 94eac0e
template <typename T>
class Foo {
public:
Foo() {
}
};
template class Foo<unsigned int>;
int main() {
Foo<int> counter;
return 0;
}
gcov: 100%
lcov: 77.8%
template <typename T>
class Foo {
public:
Foo() {
}
};
int NotCovered() {
int a = 0;
return a;
}
int main() {
Foo<int> counter;
Foo<unsigned int> counter2;
return 0;
}
gcov: 66.67%
lcov: 76.9%
I noticed the latest release of lcov (1.11) only works with gcc 4.6 and lower. With 4.7, 4.8, and 4.9, lcov immediately dies. Are there any plans to update lcov to work with the latest gcc release (4.9.2 as of this posting)?
Running LCOV version 1.12
on macOS Sierra 10.12.5
and g++ Apple LLVM version 8.1.0 (clang-802.0.42)
Consider the following simple c++ code:
#include <iostream>
int myFn(int x) {
return x * x;
}
int main(int argc, char *argv[]) {
--argc, ++argv;
std::cout << myFn(12) << std::endl;
return 0;
}
Line data Source code
1 : #include <iostream>
2 :
3 0 : int myFn(int x) {
4 1 : return x * x;
5 : }
6 :
7 0 : int main(int argc, char *argv[]) {
8 1 : --argc, ++argv;
9 :
10 1 : std::cout << myFn(12) << std::endl;
11 1 : return 0;
12 : }
PROBLEM: lines 3 and 7 are reported executable but not hit, leading to mis coverage report.
echo "--------------"
echo "-- Building --"
g++ --coverage -O0 -g0 test.cpp
echo "----------------------"
echo "-- Zeroing counters --"
lcov --zerocounters -d ./
echo "---------------------"
echo "-- Initial capture --"
lcov --capture --no-external --initial -d ./ --gcov-tool covwrap.sh -o base.info
echo "-------------"
echo "-- Running --"
./a.out
echo "---------------"
echo "-- Capturing --"
lcov --capture -d ./ --gcov-tool covwrap.sh -o test.info
echo "---------------"
echo "-- Combining --"
lcov -a base.info -a test.info -o total.info
echo "----------"
echo "-- HTML --"
genhtml total.info -o ./html
(where covwrap.sh
is simply:
#!/bin/bash
exec llvm-cov-mp-3.9 gcov "$@"
--------------
-- Building --
----------------------
-- Zeroing counters --
Deleting all .da files in ./ and subdirectories
Done.
---------------------
-- Initial capture --
Capturing coverage data from ./
Found gcov version: 3.9.1
Found LLVM gcov version 3.4, which emulates gcov version 4.2
Scanning ./ for .gcno files ...
Found 1 graph files in ./
Processing test.gcno
ignoring data for external file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__locale
ignoring data for external file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ios
ignoring data for external file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ostream
Finished .info-file creation
-------------
-- Running --
144
---------------
-- Capturing --
Capturing coverage data from ./
Found gcov version: 3.9.1
Found LLVM gcov version 3.4, which emulates gcov version 4.2
Scanning ./ for .gcda files ...
Found 1 data files in ./
Processing test.gcda
Finished .info-file creation
---------------
-- Combining --
Combining tracefiles.
Reading tracefile base.info
Reading tracefile test.info
Writing data to total.info
Summary coverage rate:
lines......: 78.6% (11 of 14 lines)
functions..: 100.0% (7 of 7 functions)
branches...: no data found
----------
-- HTML --
Reading data file total.info
Found 4 entries.
Found common filename prefix "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++"
Writing .css and .png files.
Generating output.
Processing file v1/ostream
Processing file v1/__locale
Processing file v1/ios
Processing file /bb/tmp/test.cpp
Writing directory view page.
Overall coverage rate:
lines......: 78.6% (11 of 14 lines)
functions..: 100.0% (7 of 7 functions)
I am using lcov and genhtml to generate code coverage reports. My unit test files only include the .h header files.
client_test.cpp
#include "gtest/gtest.h"
#include "../client.h"
...
lcov --capture --no-external --rc lcov_branch_coverage=1 --directory . --output-file unfiltered_coverage.info
I have noticed that the coverage report only contains coverage information for the files which were in the include section of my unit tests. Thus, the coverage report only contains the client.h file and not the client.cpp file.
I'm not entirely sure why it's the case, but sometimes geninfo ends up failing to attach a line number to functions, so the output gets FNDA: lines but no corresponding FN: lines.
I've attached a minimized pair of gcda/gcno files to this bug to illustrate the situation.
currently the included files and test files are also included.
which makes the coverage inaccurate.
Since in gcov was added possibility to distinguish exceptional block, blocks can be marked as '%%%%' and '$$$$' both. This makes it impossible to recognize the block number correctly. So, I suggest correcting it by this patch:
`
diff --git a/bin/geninfo b/bin/geninfo
index ef6a818..e4e083f 100755
--- a/bin/geninfo
+++ b/bin/geninfo
@@ -1901,7 +1901,7 @@ sub read_gcov_file($)
# Also remove CR from line-end
s/\015$//;
if (/^\s*(\d+|\$+):\s*(\d+)-block\s+(\d+)\s*$/) {
if (/^\s*(\d+|\$+|\%+):\s*(\d+)-block\s+(\d+)\s*$/) {
# Block information - used to group related
# branches
$last_line = $2;
`
Consider the following minimal example:
class A
{
public:
A() {}
virtual ~A();
};
A::~A()
{
}
int main()
{
A a;
}
Compile, run, execute lcov and genhtml:
$ g++ --coverage a.cpp
$ ./a.out
$ lcov --capture --directory . --output-file coverage.info
Capturing coverage data from .
Found gcov version: 8.2.0
Scanning . for .gcda files ...
Found 1 data files in .
Processing a.gcda
Finished .info-file creation
$ genhtml coverage.info --output-directory out
Reading data file coverage.info
Found 1 entries.
No common filename prefix found!
Writing .css and .png files.
Generating output.
Processing file /tmp/a.cpp
Writing directory view page.
Overall coverage rate:
lines......: 80.0% (8 of 10 lines)
functions..: 75.0% (3 of 4 functions)
This results in following report:
Line data Source code
1 : class A
2 : {
3 : public:
4 1 : A() {}
5 : virtual ~A();
6 : };
7 :
8 1 : A::~A()
9 : {
10 :
11 1 : }
12 0 :
13 : int main()
14 : {
15 0 : A a;
16 1 : }
The two 0
actually refer to the combined counts for destructors (GCC generates two versions of the destructor - "regular" and "deleting"). The 1
at line 16 in reality refers to line 8 again, as it is for the first version of the destructor. The rest of the counters (last counter for first version of destructor, counters for second version of destructor and counters for main()
) were just trimmed by lcov/genhtml.
This is what gcov reports for the same situation:
-: 0:Source:a.cpp
-: 0:Graph:a.gcno
-: 0:Data:a.gcda
-: 0:Runs:1
-: 0:Programs:1
-: 1:class A
-: 2:{
-: 3:public:
1: 4: A() {}
-: 5: virtual ~A();
-: 6:};
-: 7:
1*: 8:A::~A()
-: 9:{
-: 10:
1*: 11:}
------------------
_ZN1AD0Ev:
#####: 8:A::~A()
-: 9:{
-: 10:
#####: 11:}
------------------
_ZN1AD2Ev:
1: 8:A::~A()
-: 9:{
-: 10:
1: 11:}
------------------
-: 12:
1: 13:int main()
-: 14:{
1: 15: A a;
1: 16:}
As you see gcov reports them as two separate functions, with separate counters.
There is no problem if the destructor is inline in the class (or if it is not virtual).
lcov & genhtml: 1.13-15-g94eac0e (HEAD as of today)
gcc & gcov: 8.2.0
I have installed the newest git release, but that also happens in
trusty (14.04LTS) (devel): Summarise Code coverage information from GCOV 1.10-1build1 [security]: all
The code is protected, so I cannot upload files, unfortunately
Output:
stdedos@Stdedos-VirtualBox [2017-04-26 17:24:06]:/media/sf_Ubuntu_Share/code_dir$ lcov --rc lcov_branch_coverage=1 --capture --directory . --output-file coverage.info
Capturing coverage data from .
Found gcov versstr2n: 4.8.4
Scanning . for .gcda files ...
Found 7 data files in .
Processing str1/str1.gcda
/media/sf_Ubuntu_Share/code_dir/str1/str1.gcno:versstr2n '408R', prefer '408*'
/media/sf_Ubuntu_Share/code_dir/str1/str1.gcda:versstr2n '408R', prefer versstr2n '408*'
Cannot open source file /usr/include/bits/stdstr2.h
Processing str2/str2.gcda
/media/sf_Ubuntu_Share/code_dir/str2/str2.gcno:versstr2n '408R', prefer '408*'
/media/sf_Ubuntu_Share/code_dir/str2/str2.gcda:versstr2n '408R', prefer versstr2n '408*'
Cannot open source file /usr/include/bits/stdlib-float.h
Processing program.gcda
/media/sf_Ubuntu_Share/code_dir/program.gcno:versstr2n '408R', prefer '408*'
/media/sf_Ubuntu_Share/code_dir/program.gcda:versstr2n '408R', prefer versstr2n '408*'
Processing str3/str3.gcda
/media/sf_Ubuntu_Share/code_dir/str3/str3.gcno:versstr2n '408R', prefer '408*'
/media/sf_Ubuntu_Share/code_dir/str3/str3.gcda:versstr2n '408R', prefer versstr2n '408*'
Processing str4/str4.gcda
/media/sf_Ubuntu_Share/code_dir/str4/str4.gcno:versstr2n '408R', prefer '408*'
/media/sf_Ubuntu_Share/code_dir/str4/str4.gcda:versstr2n '408R', prefer versstr2n '408*'
Processing str5/str5.gcda
/media/sf_Ubuntu_Share/code_dir/str5/str5.gcno:versstr2n '408R', prefer '408*'
/media/sf_Ubuntu_Share/code_dir/str5/str5.gcda:versstr2n '408R', prefer versstr2n '408*'
Cannot open source file /usr/include/bits/stdstr2.h
Processing str6/str6.gcda
/media/sf_Ubuntu_Share/code_dir/str6/str6.gcno:versstr2n '408R', prefer '408*'
/media/sf_Ubuntu_Share/code_dir/str6/str6.gcda:versstr2n '408R', prefer versstr2n '408*'
Finished .info-file creatstr2n
stdedos@Stdedos-VirtualBox [2017-04-26 17:24:20]:/media/sf_Ubuntu_Share/code_dir$ genhtml coverage.info -f --legend --rc lcov_branch_coverage=1 --output-directory cov_out
Reading data file coverage.info
Found 10 entries.
Found common filename prefix "/media/sf_Ubuntu_Share"
Writing .css and .png files.
Generating output.
Processing file code_dir/program.c
Processing file code_dir/str1/str1.c
Processing file code_dir/str2/str2.c
Processing file code_dir/str3/str3.c
Processing file code_dir/str4/str4.c
Processing file code_dir/str5/str5.c
Processing file code_dir/str6/str6.c
Processing file /usr/include/stdlib.h
Processing file /usr/include/bits/stdlib-float.h
genhtml: ERROR: cannot read /usr/include/bits/stdlib-float.h
Directory Top-Level
stdedos@Stdedos-VirtualBox [2017-04-26 17:30:04]:/media/sf_Ubuntu_Share/code_dir/cov_out$ ls -lah
total 25K
drwxrwx--- 1 root vboxsf 4,0K Apr 26 16:41 .
drwxrwx--- 1 root vboxsf 4,0K Apr 26 17:22 ..
drwxrwx--- 1 root vboxsf 4,0K Apr 26 16:59 code_dir
-rwxrwx--- 1 root vboxsf 141 Apr 26 17:23 amber.png
-rwxrwx--- 1 root vboxsf 141 Apr 26 17:23 emerald.png
-rwxrwx--- 1 root vboxsf 9,7K Apr 26 17:23 gcov.css
-rwxrwx--- 1 root vboxsf 167 Apr 26 17:23 glass.png
-rwxrwx--- 1 root vboxsf 141 Apr 26 17:23 ruby.png
-rwxrwx--- 1 root vboxsf 141 Apr 26 17:23 snow.png
-rwxrwx--- 1 root vboxsf 117 Apr 26 17:23 updown.png
drwxrwx--- 1 root vboxsf 0 Apr 26 16:41 usr
And visual from cov_out/code_dir/index.html
I would appreciate some help and I am willing to help you test things
Hello,
Is it possible to create new 1.12 tag? We can then add recipes in MacPorts and Home Brew for Xcode 7 support
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.