linux-test-project / lcov Goto Github PK

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?

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

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;
  

`

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)

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.

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.

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%

Need a point release so homebrew can pull the fix for XCode8.

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.

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?

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!

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

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

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.

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.

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.

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

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

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

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.

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>

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

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;

Hello,

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

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

genhtml default output charset is UTF-8
codeview show up unreadable code if exists no ascii charactor in souce code and encoding is GBK
how modfiy default charset ?

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.

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.

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)

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

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.

• https://bitbucket.org/ignitionrobotics/ign-math/commits/73f0c546d8621c29700dd19b940a86e255bf7649
• working pipeline: https://bitbucket.org/ignitionrobotics/ign-math/addon/pipelines/home#!/results/1152

I then made a follow-up commit that checks out 9aa0d14, and it fails with the error message I described above:

• https://bitbucket.org/ignitionrobotics/ign-math/commits/73a4c880543f0d7e0224a5aada775127376a2d59
• broken pipeline: https://bitbucket.org/ignitionrobotics/ign-math/addon/pipelines/home#!/results/1153

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

currently the included files and test files are also included.

which makes the coverage inaccurate.

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.

Even when template code is executed the coverage is always zero.

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?

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

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

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

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!

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.

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,

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.

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!

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

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.