Giter Site home page Giter Site logo

lcov's Introduction

-------------------------------------------------
- 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.

lcov's People

Contributors

adsk-belleyb avatar ayaye avatar bilke avatar bjornfor avatar bytebunny avatar flatcap avatar gabriell avatar ggouaillardet avatar henry2cox avatar iignatev avatar jakeleventhal avatar jgonzalezdr avatar jhutz avatar ktns avatar meklort avatar nega0 avatar nehaljwani avatar oberpar avatar ojwb avatar petere avatar reinerh avatar schmidtw avatar sebastianstigler avatar skrap avatar sowhat110 avatar sztsian avatar tenta4 avatar vinicpac avatar vmiklos avatar wak-google avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lcov's Issues

Default install path conflicts with distro packages

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.

Latest binary release does to filter correctly

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)

Publish release tarballs on github.com

Please consider publishing your release tarballs on github (in addition or in replacement of SF.net). It's as simple as:

  • click on "XXX releases" from the project page
  • click on a tag ... "v1.11"
  • click the "Edit tag" button on the top right
  • Use the "Attach binaries by dropping them here or  selecting them." area

You can insert any tarball here, including the make dist product release.

Thanks!

1.14: test suite fails

+ /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

Is genhtml --show-details working?

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".

geninfo incompatible with LLVM gcov 8.0

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

Performance seems non-linear

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.

Mistake in count of line coverage

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

allow paralell gcda processing/avoid temporary files in base directory

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!

Support for MacOS needed to be improved

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.

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.

Hi,

with:

lcov: LCOV version 1.11 pre (CVS 1.98)

launching:

lcov --rc lcov_branch_coverage=1 --capture --initial -d $(BIB_OBJET_DIR)dev -d $(GIREF_OBJET_DIR)dev -o $$pref_html/BIBcoverage_dev_init.info

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

--add-tracefile fails in Ubuntu 16

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.

Feature request: Call coverage

lcov is able to show:

  • line coverage
  • branch coverage
  • function coverage

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

gcc 8 creates gcno files that are unreadable by lcov

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

Can lcov have an option that forbid it search source code files?

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!

lcov: genhtml (lcov 1.11) fails on virtual destructors

Hi,

There is an issue introduced in lcov 1.11 that fails on some virtual destructors. Attached below:

  1. sample code
  2. output from 1.11 (error)
  3. output form 1.10 (no error)
    I tested this with GCC 4.1.2, Red Hat Linux 5.

[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>

lcov 1.12 and LLVM 9.0.0 on Mac OS X 10.12.6

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.

Add anchors for every line in HTML version of source code

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.

Use Lcov in sehll script

./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"

$( ${LCOA_PATH}/lcov -b ./objs -d ./objs --capture -o output.info )
$( ${LCOA_PATH}/genhtml -o result output.info )

Mis-hit reported on class declaration due to explicit destructor present for one of members.

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.

Some code is not removed from the code coverage

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?

geninfo: Use of uninitialized value in hash element since 9aa0d14af

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:

genhtml: Negative repeat count does nothing

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.

Class member initialization in header files generated wrong lcov coverage report

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?

Allow lcov exclusion markers inside macros

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/.)

Path normalization normalizes foo/././bar incorrectly

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;

geninfo: ERROR: build/gcc/i386.gcno: could not open file

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.

geninfo incompatible with LLVM gcov 7.0

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)

lcov incompatible with GCC 9.x coverage data

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

RPM cannot be installed on CentOS 7

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.

lcov fails to parse gcov-8 output when templates are used

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.

lcov/bin/geninfo

Lines 1388 to 1394 in 94eac0e

# Write coverage information for each instrumented line
# Note: @gcov_content contains a list of (flag, count, source)
# tuple for each source code line
while (@gcov_content)
{
$line_number++;

The following two examples are based on gcov's documentation. They show the discrepancy between coverage reports by gcov and lcov.

Case 1

template <typename T>
class Foo {
 public:
  Foo() {
  }
};

template class Foo<unsigned int>;

int main() {
  Foo<int> counter;
  return 0;
}

Line Coverage Results:

gcov: 100%
lcov: 77.8%

Case 2

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;
}

Line Coverage Results:

gcov: 66.67%
lcov: 76.9%

lcov only works with gcc 4.6 and lower

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)?

lcov --initial generates mis-hit for signature in function definition

Versions

Running LCOV version 1.12 on macOS Sierra 10.12.5 and g++ Apple LLVM version 8.1.0 (clang-802.0.42)

Code snippet

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;
}

Coverage result

   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.

Steps to reproduce

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 "$@"

Output

--------------
-- 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)

LCOV is generating coverage reports for only header files

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.

geninfo somehow forgets the line number of functions

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.

gcda_pair.zip

Geninfo can't parse block number

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;
    

`

Non-inline virtual destructors not parsed correctly by lcov - results in wrong lines

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

genhtml does not generate top-level html file or a way to enter sub-directories

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

image

I would appreciate some help and I am willing to help you test things

New 1.12 tag

Hello,

Is it possible to create new 1.12 tag? We can then add recipes in MacPorts and Home Brew for Xcode 7 support

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.