gcovr/gcovr

generate code coverage reports with gcc/gcov

gcovr

generate GCC code coverage reports

website and documentation • bugtracker • GitHub

Gcovr provides a utility for managing the use of the GNU gcov utility and generating summarized code coverage results. This command is inspired by the Python coverage.py package, which provides a similar utility for Python.

The gcovr command can produce different kinds of coverage reports:

CLI Option	User Guide	Description
default, --txt	Text Output	compact human-readable summaries
--html	HTML Output	overview of all files
--html-details	HTML Output	annotated source files
--html-template-dir	HTML Output	use custom set of Jinja2 templates
--csv	CSV Output	CSV report summarizing the coverage of each file
--json	JSON Output	JSON report with source file structure and coverage
--json-summary	JSON Output	JSON summary coverage report
--clover	Clover XML Output	machine readable XML reports in Clover format
--cobertura	Cobertura XML Output	machine readable XML reports in Cobertura format
--coveralls	Coveralls JSON Output	machine readable JSON report in Coveralls format
--jacoco	JaCoCo XML Output	machine readable XML reports in JaCoCo format
--lcov	LCOV info Output	machine readable report in LCOV info format
--sonarqube	SonarQube XML Output	machine readable XML reports in SonarQube format

Thus, gcovr can be viewed as a command-line alternative to the lcov utility, which runs gcov and generates an HTML-formatted report. The development of gcovr was motivated by the need for text summaries and XML reports.

Example HTML summary:

Example HTML details:

Installation

Gcovr is available as a Python package that can be installed via pip.

Install newest stable gcovr release from PyPI:

pip install gcovr

Install development version from GitHub:

pip install git+https://github.com/gcovr/gcovr.git

Quickstart

GCC can instrument the executables to emit coverage data. You need to recompile your code with the following flags:

--coverage -g -O0

Next, run your test suite. This will generate raw coverage files.

Finally, invoke gcovr. This will print a tabular report on the console.

gcovr

You can also generate detailed or nested HTML reports:

gcovr --html-details coverage.html
gcovr --html-nested coverage.html

Gcovr will create one HTML report per source file and for --html-nested also per directory next to the coverage.html summary.

You should run gcovr from the build directory. The -r option should point to the root of your project. This only matters if you have a separate build directory. For example:

cd build; gcovr -r ..

For complete documentation, read the manual.

Contributing

If you want to report a bug or contribute to gcovr development, please read our contributing guidelines first: https://github.com/gcovr/gcovr/blob/main/CONTRIBUTING.rst

License

Copyright (c) 2013-2024 the gcovr authors Copyright (c) 2013 Sandia Corporation. Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software.

This software is distributed under the 3-clause BSD License. See LICENSE.txt for full details. See AUTHORS.txt for the full list of contributors.

Gcovr development moved to this repository in September, 2013 from Sandia National Laboratories.

gcovr's Issues

Using gcovr html details on windows

When using the command (gcovr --html --html-details) on cmd windows it don't work.
I think because of the paths that are interpreted in a way that windows doesn't understand it. The error is:
IOError: [Errno 2] No such file or directory: 'E:user\PGA_Source_Code\PGA_prg.c'

I think the "//" is not interpreted correctly in windows.

Please I need help with this urgently

Generated html links for --html-detail are absolute

The html links for the files should be relative rather than absolute.

e.g. Project x with foo.cpp I generate the top level page:

/home/jam/public_html/x.html

that contains a link to the file coverage for x.cpp but that is referenced in the html as:

/home/jam/public_html/foo.cpp.html

the "a href" in the html should reference foo.cpp.html relatively and not the whole path as above because when you visit the page in the browser, e.g.:

www.example.com/~jam/x.html

it then has a hyperlink that resolves to

www.example.com/home/jam/public_html/foo.cpp.html

which clearly won't work. The a href should just be:

foo.cpp.html

which will work fine as the html-detail files are only ever generated in the same directory as the top level html.

switch issue

With the following code I expect to get 100% branch coverage:

#include <stdio.h>

void do_switch(int len) {
    switch (len & 1) {
        case 1:
            printf("one\n");
            break;
        case 0:
            printf("zero\n");
            break;
    }
}

int main() {
    do_switch(1);
    do_switch(0);
    return 0;
}

But it claims that I missed one branch.

Changing case 0: to default: gives the expected results.

gcovr --html is failing without an interesting error message

$ mkdir foodir
$ cd foodir/
$ gcovr --html
Traceback (most recent call last):
  File "/usr/bin/gcovr", line 1845, in <module>
    print_html_report(covdata, options.html_details)
  File "/usr/bin/gcovr", line 1285, in print_html_report
    dir_, file_ = os.path.split(filtered_fname)
UnboundLocalError: local variable 'filtered_fname' referenced before assignment

I should get a better error message.

gcovr does not work with CMake out-of-source builds

gcovr is not able to locate source files when doing an out-of-source build with cmake whose build directory is not in the source tree, i.e.:

mkdir /home/user/build
cd /home/user/build
cmake /home/user/source/project
make
ctest

This will generate the *.gcno and *gcda in target-specific subdirectories of the directory /home/user/build/CMakeFiles. Running

gcovr -v -r /home/user/source/project

does not locate any coverage data files.

gcovr -v --object-directory=/home/user/build/CMakeFiles -r /home/user/source/project

does not locate any coverage data files, either.

gcovr cannot find source files with gcov 4.8.2

The fix from https://software.sandia.gov/trac/fast/ticket/3860 no longer works with gcov 4.8.2.

****** 3860 Description *****
I'm having problem with gcovr which don't see my source code. I have my code organized in following way

$ROOT/src -> all *.cpp files
$ROOT/include -> all *.h files
$ROOT/obj -> all *.o files
$ROOT/lib -> for libs
$ROOT/bin -> for binaries

• tests are organized in this way (not important)

$ROOT/test/src
$ROOT/test/bin
$ROOT/test/obj

Now, I run gcovr in the following way:

cd $ROOT
gcovr_wrapper -x -b -r $ROOT -e $ROOT/test
gcovr complains that he couldn't find the source code. Quick solution is to copy $ROOT/src and $ROOT/include to $ROOT/obj, but this only works with small projects. It would be much better to tell gcovr where to look for source files. Do you know if it is possible in current implementation of gcovr? If not then does anybody has an idea if it would be feasible to implement?
***** end 3860 Description *****

***** original 3860 resolution ******
r2378 introduces new gcovr logic: if gcov tosses an error, gcovr will attempt to re-run gcov from higher in the directory tree (specifying the original directory through the --object-directory argument). gcovr will traverse up to the system root directory if necessary (and then throw a warning summarizing all errors tossed by gcov if gcov is still not happy).

This now correctly runs the provided test case.
***** end original 3860 resolution ******

Research shows that gcov 4.8.2 changed the stderr message format to

"Cannot open source file"

whereas gcov 4.5.2 and previous stderr message was

"cannot open source file".

Resolved by changing line 63 from "cannot" to "[Cc]annot".

filename without path in XML output

Hi,

Right now both filename and name have almost the same value in XML output when --root is used.
Example:

class branch-rate="0.615384615385" complexity="0.0" filename="a.cpp" line-rate="0.364444444444" name="a_cpp"

In previous versions filename contained relative path from --root to the file, example:

class branch-rate="0.615384615385" complexity="0.0" filename="src/abc/a.cpp" line-rate="0.364444444444" name="a_cpp"

This is a breaking change that causes Sonar plugin to not work. Could the old behavior be restored? Or at least configured via command line?

Regards, Lukasz

gcovr with html option is not working for nested directory structure

Let's say i have 4-level directory structure where 3rd level directory has multi directory structure. In the html report it's considering only a single path, that means if level 4 directories are a,b,c,d then it's only having l1->l2->l3->a

Display branches in HTML

LCov displays taken, not-taken and unreachable branches in HTML report with [-], [+] and [#].
Could GCovr also be updated with something like that? This data is already inside it and ends up in XML report, so maybe add it HTML also?

From .gcda & ,gcno to XML or HTML, how does gcovr do it??

My gcovr version is gcovr-3.2, there are mainly 5 functions in the source code,. the followings :

1: def get_datafiles(flist, options): line:322 to get gcda & gcno files
2: def process_gcov_data(file, covdata, options): line:347 process the data of gcda & gcno

3: def process_datafile(filename, covdata, options): line:472 the most important one for processing data

4: def print_text_report(covdata): line:616 Produce the classic gcovr text report

5: def print_xml_report(covdata): line:666 Produce an XML report in the Cobertura format

I want to know how does gcovr provide the XML report or HTML report , which function , which line, ???? Because python is too hard for me

--branch-probabilities should be optional

Basically, we updated the gcovr script to not pass the "—branch-probabilities" option to gcov, which has the effect of only reporting line coverage and not branch coverage. In other words, we don't want branch coverage. Initially we did, but then we realized that it was confusing with C++ since the compiler adds extra branches. Does that make more sense?

wrong behaviour with -r --root parameter

ReleaseNotes:

• Change to make the -r/--root options define the root directory
  for source files.
  gcovr -h:
  -r ROOT, --root=ROOT Defines the root directory. This is used to filter
  the files, and to standardize the output.

Root directory should be treated as a filter for not including files above this directory. For now is used as a source directory with .gcda/.gcno files so script doesn't work if .gcda/.gcno files are in different place.
E.g.
~/x/y/zproject - root directory with Makefile and sources in subdirectories
~/build - output directory for gcc
~/build/coverage_res - directory with result files (.gcda & .gcno)

command "cd ~/build/coverage_res && gcovr -r ~/x/y/zproject" doesn't find any files

1826c1825,1828

< datafiles = get_datafiles(["."], options)

if options.root is None:
    datafiles = get_datafiles(["."], options)
else:
    datafiles = get_datafiles(options.root, options)

Clarify semantics for the --object-directory option

The gcovr code includes comments that indicates that the --object-directory option should be same one used by gcovr. This is not obvious from the gcovr --help documentation. Additionally, this option is not used by the get_datafiles() function to search for .gc files. That seems like a bug, but I'm not sure.

Relative source paths and file name resolution

I am building a project broken-down by multiple internal libraries and binaries, each with a separate relative directory similar to
{{{
/trunk/libA/sourceA.h
/trunk/libA/sourceA.cpp
/trunk/libB/sourceB.h
/trunk/libB/sourceB.cpp
/trunk/binC/sourceC.cpp
}}}
I'm building with qmake and an built-object directory for each sub-project, which results in the binary outputs of
{{{
/trunk/libA/o/sourceA.o
/trunk/libA/libA.so
/trunk/libB/o/sourceB.o
/trunk/libB/libB.so
/trunk/binC/o/sourceC.o
/trunk/binC/binC
}}}

When I run the gcov-instrumented binary within {{{/trunk/binC}}} directory, I get output files for all of the proper sources but some of the outputs have parent-relative path names that gcovr does not resolve properly.

One of the intermediate {{{.gcov}}} files is {{{/trunk/binC/o/^#libA#sourceA.cpp.gcov}}} containing the line
{{{
-: 0:Source:../libA/sourceA.cpp
}}}
which is as expected, but gcovr resolves this relative path as
{{{
/trunk/binC/o/libA/sourceA.cpp
}}}
which is not correct. It really should be
{{{
/trunk/binC/../libA/sourceA.cpp
}}}

I have added a patch to my local version to specify a prefix to use just before {{{os.path.abspath}}} in {{{process_gcov_data}}} function, but I'm not sure if this is the correct approach or if there is a better method already available in gcovr. The prefix corresponds to the original build directory of the binary, which is kind of opposite of the existing {{{--object-directory}}} option.

(from gcovr ticket 3958)

Incorrect use of commonprefix creating nonsensical hrefs

The code:

(https://github.com/gcovr/gcovr/blob/master/scripts/gcovr#L1412)

    if len(files) > 1:
        commondir = posixpath.commonprefix(files)
        if commondir != '':
            data['DIRECTORY'] = commondir
    else:
        dir_, file_ = os.path.split(filtered_fname)
        if dir_ != '':
            data['DIRECTORY'] = dir_ + os.sep

sometimes creates nonsensical file names. I think what you want to do is remove the common path from all files, but retain the file name. commonprefix does not do that. For example I have two file names:

my_class.hpp
my_class_test.cpp

gcovr creates an html file with names:

.hpp
_test.cpp

which obviously wasn't the intention.

To calculate the commondiryou should either use commonprefix and then walk back to the first os.path.sep, or use os.path.walk on all paths checking for equality. Sorry, no patch yet as I'm basing my understanding of the issue on a quick read of the code.

python3 support

python3 is not supported

Traceback (most recent call last):
  File "/usr/src/gcovr/scripts/gcovr", line 1836, in <module>
    process_datafile(file,covdata,options)
  File "/usr/src/gcovr/scripts/gcovr", line 738, in process_datafile
    process_gcov_data(fname, covdata, options)
  File "/usr/src/gcovr/scripts/gcovr", line 404, in process_gcov_data
    line = INPUT.readline()
  File "/usr/lib64/python3.3/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 403: invalid start byte

gcovr generated report does not include cpp file.

Hi

I am using gcovr to generate report that can be used by cobertura plugin on Jenkins. However, the plugin only shows coverage details for hpp files, not cpp files. I repeated the process manually and find out that gcovr generated report does not contain information about cpp files. Any idea?

Thanks,

Test coverage (statement, branch, decision) for iOS

Hello,

Can I have the information of branch, decision and statement coverage with gcovr and XCode? Or there is any other tool I can use?

Thanks

add "--add-tracefile" like lcov

I want to merge two gcda result into one.
lcov can use --add-tracefile do the work, how gcovr do it? Thanks

Filename length on Windows

Users have reported an issue with very long filenames on Windows. This needs to be checked, but no test cases have been provided

Uncovered files not reported when using gcov 4.7

gcovr 3.1 does not include uncovered files in its report when used in conjunction with gcov 4.7.2 (on Ubuntu 12.10).

From examination, it seems the issue might stem from gcov 4.7.2 not producing .gcov files for source files that do not have corresponding .gcda files.

Separately invoking gcov on an uncovered source file produces output indicating that no .gcov file is generated. E.g.:
gcov src/Foo.cpp --branch-counts --branch-probabilities --preserve-paths --object-directory build/src
produces output containing:

File 'src/Foo.cpp'
No executable lines
No branches
No calls
Removing 'src#Foo.cpp.gcov'

Where Foo.cpp is not exercised by test code.

Memory Usage for XML output is very high

For my project (Gromacs) the memory usage of gcovr is extremely high when using the XML output (-x). It tops at about 1GB. This is with the version from https://software.sandia.gov/trac/fast/export/2745/gcovr/trunk/scripts/gcovr

(from ticket 3922)

"relative referencing in --object-directory" false positive if path ends with slash

Hi

If one uses a path ending with a slash than this error message appears:
WARNING: relative referencing in --object-directory; this could" cause strange errors when gcovr attempts to identify" the original gcc working directory.

Even though there is no relative referencing in the path.
Problem:
os.path.normpath() strips the last / but objdir.replace('/',os.sep) does not.

Verify MS Windows behavior

When i am using Gcovr through CygWin? With the required file(ie .gcno and .gcda ),i am getting the code coverage results on console as well as in .xml file.But when i am using the same on command prompt(in windows),i dont get the code coverage data.I am just returned with an empty table having coverage data as 0.0.
Configuratio used :
os:Windows XP
gcov version:3.4.5
compiler:Mingw
gcovr version:2.4

gcovr: Using --filter does not display filename

When I run this:

gcovr -v -r $ROOT biz/Merchant/Payment/Checkout/PaymentSolution/ --gcov-filter='.biz#Merchant.'

It generates the correct output:

{{{

Gathered coveraged data for 6 files

File Lines Exec Cover Missing

biz/Merchant/Payment/Checkout/PaymentSolution/PaymentSolution.h
2 2 100%
biz/Merchant/Payment/Checkout/PaymentSolution/implementation/PaymentSolutionBuyNow.cpp
19 18 94% 41
biz/Merchant/Payment/Checkout/PaymentSolution/implementation/PaymentSolutionBuyNow.h
1 1 100%
biz/Merchant/Payment/Checkout/PaymentSolution/implementation/PaymentSolutionDefault.cpp
19 7 36% 32-35,39-42,46-49,52-58,62-64
biz/Merchant/Payment/Checkout/PaymentSolution/unit_test/PaymentSolutionBuyNowTestSuite.cpp
38 37 97% 112
biz/Merchant/Payment/Checkout/value_object/CheckoutSessionVO.h_gen

1 1 100%

TOTAL 80 66 82%

}}}

But when I use the --filter option, the filenames are not listed:

gcovr -v -r $ROOT biz/Merchant/Payment/Checkout/PaymentSolution/ --filter='.biz/Merchant.'

{{{

Gathered coveraged data for 6 files

File Lines Exec Cover Missing

                                           2       2   100%   
                                          19      18    94%   41
                                           1       1   100%   
                                          19       7    36%   32-35,39-42,46-49,52-58,62-64
                                          38      37    97%   112
                                           1       1   100%   

---

TOTAL 80 66 82%

}}}

(from gcovr ticket 3925)

symbolic link, match error

Hello,

Thanks for your script, it's very usefu! :)

But since the v3.1, there is an error if the root dir is a symbolic link.
Inside the method process_gcov_data at line:

       if options.filter[i].match(fname):
           filtered_fname = options.root_filter.sub('',fname)
           break

For example :
filter = /private/tmp/myProject/
fname = /tmp/myProject/../Tests/TestCases/Model/.../MyFile.m

/tmp is a symbolic link to /private/tmp (Mac OSX)

Any idea for fix this issue?

Support out of source tree builds

This does not work for me:

cd /tmp/builds/project1;
/bin/python /home/user1/gcovr/scripts/gcovr -v -x -r /home/user1/project1 --object directory=/tmp/builds/project1 -o /home/user1/coverage.xml

I get the following output:

Scanning directory /home/user1/project1 for gcda/gcno files...
Found 0 files (and will process 0)
Gathered coveraged data for 0 files

I expected gcovr to use the path given by the --object-directory option to look for gcda/gcna files, while using the -r option to specify where the source files are, but it appears just look in the path given by -r.

Parent as object-directory gives coercing to Unicode error

With gcovr v2774, using the parent directory for object-directory produces this error:

gcovr —verbose —object-directory=..
Traceback (most recent call last):

    File "/home/me/bin/gcovr", line 977, in <module>

Scanning directory . for gcda/gcno files…
Found 4 files (and will process 2)

    process_datafile(file,covdata,options)

        File "/home/me/bin/gcovr", line 499, in process_datafile

            for f in os.listdir(d):

TypeError?: coercing to Unicode: need string or buffer, list found

Adding some prints to gcovr in process_datafile() shows:

dirs=[[, 'home', 'me', 'top', 'test', 'unittest.gcda']]
d=[, 'home', 'me', 'top', 'test', 'unittest.gcda']

, so os.listdir(d) is complaining about getting a list.

Steps to reproduce:

mkdir -p top/test
echo 'void func01(void) { int x=1245; }' > top/top.c
cat <<FILE > top/test/unittest.c
extern void func01(void);
int main(int argc, char* argv[])
{
func01();
return 0;
}
FILE
cat << MAKE > top/test/Makefile
OBJS=../top.o unittest.o
LD_FLAGS=-fprofile-arcs
unittest: $(OBJS)
gcc (LD_FLAGS)
%.o: %.c
gcc —coverage -c -o <
MAKE
cd top/test
make
gcovr —verbose —object-directory=..

Traceback when called without "-r" / "--root" parameter

Calling gcovr 3.2 without the root parameter gives this traceback:

------------------------------------------------------------------------------
                           GCC Code Coverage Report
Traceback (most recent call last):
  File "/usr/bin/gcovr", line 1972, in <module>
    print_text_report(covdata)
  File "/usr/bin/gcovr", line 822, in print_text_report
     OUTPUT.write("Directory: "+options.root+"\n")
TypeError: cannot concatenate 'str' and 'NoneType' objects

gcovr 3.1 gave an empty but more friendly output:

------------------------------------------------------------------------------
File                                       Lines    Exec  Cover   Missing
------------------------------------------------------------------------------
------------------------------------------------------------------------------
TOTAL                                          0       0    --%
------------------------------------------------------------------------------

I would prefer to either return to the behavior of 3.1, or to print a message stating what the problem is. Maybe setting options.root to a default value before using it the first time would be enough already.

0/0 is not 100%

0/0 situations should be either hidden completely or have a NaN value.

Gcovr fails sometimes with "string index out of range"

Here's full call stack:

Traceback (most recent call last):
File "/usr/local/build-system/cpp/tools/gcovr/scripts/gcovr", line 1961, in
process_datafile(file_,covdata,options)
File "/usr/local/build-system/cpp/tools/gcovr/scripts/gcovr", line 749, in process_datafile
process_gcov_data(fname, covdata, options)
File "/usr/local/build-system/cpp/tools/gcovr/scripts/gcovr", line 507, in process_gcov_data
if tmp[0] == '-' or (excluding and tmp[0] in "#=0123456789"):
IndexError: string index out of range

What might cause it?

gcovr --html-details does not work with stand-alone builddirs

Example

mkdir build; cd build
../configure --toolchain=gcov
make && make fate
gcovr -b -r .. --object-directory . --html --html-details -o t.html

Result

Traceback (most recent call last):
  File "/usr/bin/gcovr", line 1767, in <module>
    print_html_report(covdata, options.html_details)
  File "/usr/bin/gcovr", line 1311, in print_html_report
    INPUT = open(data['FILENAME'], 'r')
IOError: [Errno 2] No such file or directory: 'avconv.c'

avconv.c is in ..

Add tests for directories that contain dots in the path name

Confirm that gcovr will work in a directory such as /home/user/.jenkins/workspace

Verify gcovr link semantics

I reworked the link-following semantics in gcovr. See 49f8535.

This uses os.realpath to get the real path information, and it uses os.walk to traverse through symbolic links (for python >= 2.6).

Can you verify that this logic works as expected? We don't have any tests in gcovr that exercise the symbolic links, so that's part of this ticket. Were there specific 'bad' cases that we should implement? I could implement something based on the link example in the gcovr code, but I'm not sure where the files would be to exercise the gcovr badness ...

I'm OK reverting these changes, but I'd like to see a case study to motivate the currentl logic.

Possible to speed up gcovr on big projects?

hi,

i've written a tool, which uses gcovr to generate coverage reports for a big project. i am selectively instrumenting files based on a diff file users pass in (ie if the user changed file1, file2, file3, then touch these files and do a make with gcov flags enabled). in some cases, especially when a user touches a commonly included header file, hundreds of gcno files are created (i presume wherever these header files are included and possibly recursively?). in these cases, gcovr takes up to 3 hours to complete its analysis. i'm curious if there's a safe (maintains coverage accuracy) way for me to speed things up?

Issue with version 3.0 from pypi: cannot find README.md

I could not install gcovr version 3.0 with pip from either in a regular system (with 2.7) or a virtualenv (with 2.6).

Downloading/unpacking gcovr from https://pypi.python.org/packages/source/g/gcovr/gcovr-3.0.tar.gz#md5=7862bbfa14d0cea66a7c8fb2cc7e9f0e
  Downloading gcovr-3.0.tar.gz
  Running setup.py egg_info for package gcovr
    Traceback (most recent call last):
      File "<string>", line 16, in <module>
      File "/tmp/pip-build/gcovr/setup.py", line 33, in <module>
        long_description = read('README.md'),
      File "/tmp/pip-build/gcovr/setup.py", line 19, in read
        return open(os.path.join(os.path.dirname(__file__), *rnames)).read()
    IOError: [Errno 2] No such file or directory: '/tmp/pip-build/gcovr/README.md'
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

  File "<string>", line 16, in <module>

  File "/tmp/pip-build/gcovr/setup.py", line 33, in <module>

    long_description = read('README.md'),

  File "/tmp/pip-build/gcovr/setup.py", line 19, in read

    return open(os.path.join(os.path.dirname(__file__), *rnames)).read()

IOError: [Errno 2] No such file or directory: '/tmp/pip-build/gcovr/README.md'

----------------------------------------
Command python setup.py egg_info failed with error code 1 in /tmp/pip-build/gcovr
Storing complete log in /home/harter/.pip/pip.log

Given root directory is not used when creating a html report

When using the option --root={SOURCE_DIR} --html --html-details i get an error.

In the following line the root directory should be added:
https://github.com/gcovr/gcovr/blob/master/scripts/gcovr#L1369

Possible fix:

INPUT = open(os.path.join(options.root,data['FILENAME']), 'r')

Backslash in file name

Please update lines 1472 and 1477 in scripts/gcovr which assemble the cdata._sourcefile string (function print_html_report). Today code replaces Unix slash with underscore but not the Windows backslash and colon characters so gcovr doesn't work. I have updated my local copy and with this small change it works very well with Windows (unline LCov which requires much more updates :( ).

Edit: maybe it's even nicer to add a separate function which creates OS safe file name?

gcovr performance issue

After looking into this one a bit more, I did an strace and it looks like issue is that gcovr is going through a ton of files that are not gcno/gcda files and is a huge change to performance from the previous version.
This performance issue is still occuring in 2823 and appears to be due to this section of code:
269 def link_walker(path):
270 targets = [os.path.abspath(path)]
271 while targets:
272 target_dir = targets.pop(0)
273 actual_dir = resolve_symlinks(target_dir)
274 #print "target dir: %s (%s)" % (target_dir, actual_dir)
275 master_name, master_base, visited = aliases.master_path(actual_dir)
276 if visited:
277 #print " ...root already visited as %s" % master_name
278 aliases.add_alias(target_dir, master_name)
279 continue
280 if master_name != target_dir:
281 aliases.set_preferred(master_name, target_dir)
282 aliases.add_alias(target_dir, master_name)
283 aliases.add_master_target(master_name)
284 #print " ...master name = %s" % master_name
285 #print " ...walking %s" % target_dir
286 for root, dirs, files in os.walk(target_dir, topdown=True):
287 #print " ...reading %s" % root
288 for d in dirs:
289 tmp = os.path.abspath(os.path.join(root, d))
290 #print " ...checking %s" % tmp
291 if os.path.islink(tmp):
292 #print " ...buffering link %s" % tmp
293 targets.append(tmp)
294 yield root, dirs, files
This issue is occuring with the following python version:
2.6.4 (r264:75706, Feb 7 2013, 11:31:38)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]

gcovr confused by duplicate filenames

I saw this issue in a test project where some coverage data was not showing up in the gcovr generated reports.

I believe as of gcovr 3.2, all gcov reports are ran from starting_dir and output is stored in this single directory but nothing in filename contains subdirectory info.

Here is a made up project layout that has plugins for various audio formats:

root/src/main.cpp
root/src/read.cpp
root/src/mp3/read.cpp
root/src/wav/read.cpp

read.cpp.gcov would be generated in root directory 3 times and overwrite each other.

In my tests, only root/src/read.cpp shows up in reports because it happens to be last gcov ran.

feature: add side frame which shows functions outline for html output

when you click a foo.cpp to view its detailed coverage, you should keep scrolling down to the specified function you want to see.
just like that we can navigate to the specified function easily with a outline of functions in IDE like eclipse.
is it a reasonable feature?

Support multiple filter options

Support multiple —filter options in same manner as —exclude option.
It is benficial to have possiblity to use gcovr as following:

gcovr —filter=".*some_files.*" —filter=".*some_other_files.*" —exclude=".*some_file_matched_by_filter.*" —root="/my_root_path"

Submits a solution proposal, which depends on my patch attached in ticket 3925 (gcovr: Using —filter does not display filename)

Provide css/template overrides for the html output.

Beside what lcov does, would be nice having proper templating so a twitter bootstrap structure can be leveraged.

parallelize main loop of gcovr

It takes a long time to run gcovr on a large project, especially when used as part of an automated analysis system. It would be nice if this loop were parallel:

for file in datafiles:
  process_datafile(file,covdata,options)

(from gcovr ticket 3956)

Gcovr generate empty coverage report

I used following command to generate code coverage report for ios application but it generate empty report .
gcovr -r . --html -o ~/Desktop/example1.html

It says 0 lines executed and 0% coverage even if .gcno and .gcda files are generated .

#4 broke html reports

The fix for #4 apparently broke HTML reports as I get errors about options.filter.sub not being available. The fix is:

diff -r c5193e657ac7 gcovr
--- a/gcovr   Tue Sep 10 09:10:01 2013 -0600
+++ b/gcovr   Tue Sep 10 09:55:29 2013 -0600
@@ -1199,25 +1204,27 @@
     #
     for f in keys:
         cdata = covdata[f]
-        dir = options.filter.sub('',f)
-        if f.endswith(dir):
-            src_path = f[:-1*len(dir)]
-            if len(src_path) > 0:
+        if (len(options.filter) > 0):
+          for i in range(0,len(options.filter)):
+            dir = options.filter[i].sub('',f)
+            if f.endswith(dir):
+              src_path = f[:-1*len(dir)]
+              if len(src_path) > 0:
                 while dir.startswith(os.path.sep):
-                    src_path += os.path.sep
-                    dir = dir[len(os.path.sep):]
-                source_dirs.add(src_path)
-        else:
-            # Do no truncation if the filter does not start matching at
-            # the beginning of the string
-            dir = f
-        files.append(dir)
-        cdata._filename = dir
-        ttmp = options.output.split('.')
-        if len(ttmp) > 1:
-            cdata._sourcefile = '.'.join( ttmp[:-1] )  + '.' + cdata._filename.replace('/','_') + '.' + ttmp[-1]
-        else:
-            cdata._sourcefile = ttmp[0] + '.' + cdata._filename.replace('/','_') + '.html'
+                  src_path += os.path.sep
+                  dir = dir[len(os.path.sep):]
+              source_dirs.add(src_path)
+            else:
+              # Do no truncation if the filter does not start matching at
+              # the beginning of the string
+              dir = f
+            files.append(dir)
+            cdata._filename = dir
+            ttmp = options.output.split('.')
+            if len(ttmp) > 1:
+              cdata._sourcefile = '.'.join( ttmp[:-1] )  + '.' + cdata._filename.replace('/','_') + '.' + ttmp[-1]
+            else:
+              cdata._sourcefile = ttmp[0] + '.' + cdata._filename.replace('/','_') + '.html'
     if len(files) > 1:
         commondir = posixpath.commonprefix(files)
         if commondir != '':

Or something like that...

incorrect abspath for gcov data file

when the gcov file is generated under sub directory, the relative path is still resolved to abs path related to root_dir. The abs path should be resolved related to the CWD.

code snippet:

def process_gcov_data(data_fname, covdata, options):
    INPUT = open(data_fname,"r")
    #
    # Get the filename
    #
    line = INPUT.readline()
    segments=line.split(':',3)
    if len(segments) != 4 or not segments[2].lower().strip().endswith('source'):
        raise RuntimeError('Fatal error parsing gcov file, line 1: \n\t"%s"' % line.rstrip())
    currdir = os.getcwd()
    os.chdir(root_dir) # <==== Following fname will be calculated related to root_dir
    if sys.version_info >= (2,6):
        fname = os.path.abspath((segments[-1]).strip())
    else:
        fname = aliases.unalias_path(os.path.abspath((segments[-1]).strip()))
    os.chdir(currdir)

fix available at kevincai@fcce760.

Test passed with expected result.

Split main script into a module

This seems inevitable.
#43 does this.
#25 and the implementation of a better HTML/CSS engine depends on this. Come on, the current engine is high memory copy based and CSS is embedded into the very same HTML and script code, and is HTML from 1998. We need to improve this situation.

One argument to remain as it is now is the ability to quickly download and use the script anywhere you needed. On the other hand, the pip based distribution model doesn't care about this. It will not change the current distribution model as a whole. People uses pip to install it (opposed to download and execute the script directly) so there is not much left to say about making it a module.

Making gcovr a module and not a single script will improve the current state of the code base, will improve collaboration and better engineering practices, will allow gcovr to be used as a library for custom worflows and will allow to port the HTML engine to something more modern.

Please do consider this. I already have done the refactoring and I can push a pull request but this needs to be decided by the team first.

Regards,

gcovr is dead when specify full path

$ pwd
/home/xsyr/workspace/cppprojects/ptp/build
$ gcovr -x -o report.xml -r ..            <------ It works fine.
$ gcovr -x -o report.xml -r /home/xsyr/workspace/cppprojects/ptp/
..... No response for a long time.

--root option fails for multicharacter paths

In script/gcovr, function find_data_files(flist, options) iterates the directories in flist to find data files. This is done with a "for ... in ..." loop, which iterates over individual characters of a multiple character path.

gcovr/scripts/gcovr -r "tests/are/here/"

The above will fail because the directory "t" does not exist. Instead, it should treat the path as a whole and check the directory "tests/are/here/". I'd expect it to split on whitespace.