Geninfo error: gcov did not create any files for ***.gcda!

[silverbullet-21]

Command: lcov --capture --directory ./ --no-external --rc lcov_branch_coverage=1 --output-file src_coverage.info

Error message: Capturing coverage data from ./ Found gcov version: 4.8.5 Scanning ./ for .gcda files ... Found 1 data files in ./ Processing lm.gcda /home/file1.gcda:cannot open data file, assuming not executed geninfo: WARNING: gcov did not create any files for /home/file1.gcda! Finished .info-file creation

Note: .gcda file was created before (using touch command - part of legacy code) but it is empty. .gcno file for file1.cpp is already present (created during compilation) lcov --version => 1.15

• Not facing this issue on another server with gcc version 4.4.7 and lcov version 1.14.

Is this error due to any version mismatch?

[henry2cox]

If you search “./” for .gcda and .gcno files…what do you find? Are permissions set such that you can read them?

When you look at the extracted .info file from 1.14 and 1.15, are the contents different? That is: did extraction fail or produce a different/possibly incorrect result – or is the only issue that there was a warning/message about an unexpectedly empty file?

(I haven’t tried to reproduce the issue by creating an empty .gcda file to see what would happen.)

Henry

[silverbullet-21]

If you search “./” for .gcda and .gcno files…what do you find? Are permissions set such that you can read them? When you look at the extracted .info file from 1.14 and 1.15, are the contents different? That is: did extraction fail or produce a different/possibly incorrect result – or is the only issue that there was a warning/message about an unexpectedly empty file? (I haven’t tried to reproduce the issue by creating an empty .gcda file to see what would happen.) Henry

Searching for .gcda and .gcno files in './' returns file1.gcno (size ~ 38k), file1.gcda (size = 0) and both read and write permissions are set (-rw-rw-r--.)

Yes, the contents of extracted .info file from 1.14 and 1.15 are different. src_coverage.info (generated using gcc 4.4.7 and 1.14) contains much more content like: TN: SF:/home/file1.cpp FN:1737,_ZL17func1h FN:1749,_ZL17func2j FN:2596,_ZL23func3v FNDA:0,_ZL17func1h FNDA:0,_ZL17func2j FNDA:0,_ZL23func3v FNF:3 FNH:0 BRDA:2599,0,1,- BRDA:2599,0,2,- . . . src_coverage.info (generated using gcc 4.8.5 and 1.14/1.15) contains only: TN:

The extraction failed and produced an incorrect result along with the warning message.

[henry2cox]

The path “/home/file2.hpp” in the ‘coverage.info’ file from 1.14 looks suspicious.

I suspect that the source paths seen by your compiler and those seen later are different.

•      What is the full path to “./” in your ‘lcov –extract’ call?
  

•      Can you grep through the coverag.info file, looking for every line of the form “SF: ..” – and then verify whether there is a file there or not.
  

The other question is what the compile line for ‘file1.cpp’ and the link line for your test executable look like.

If you had a testcase which reproduces the issue – that would be most helpful.

Henry

[silverbullet-21]

• file2.hpp is actually file1.cpp (typo)

• My unit under test file 'file1.cpp' and generated files (file1.gcda, file1.gcno and file1.o) are present in: /home/dir0/dir1/dir2/dir3/dir4/dir5/dir6/dir7 (names modified) For executing lcov command, my python script is changing current directory to this directory and it is in this directory, Python script is invoking the following lcov command: lcov --capture --directory ./ --no-external --rc lcov_branch_coverage=1 --output-file src_coverage.info

• Have reproduced the test case. Please follow below commands:

$ echo "const int a = 5; int main(void) { return 1;}" > t.c $ gcc -Wall -Wextra -Werror ./t.c --coverage $ touch t.gcda $ lcov --capture --directory ./ --no-external --rc lcov_branch_coverage=1 --output-file src_coverage.info

[henry2cox]

You have to run your executable to generate (runtime) coverage data:

$ echo "const int a = 5; int main(void) { return 1;}" > t.c $ gcc -Wall -Wextra -Werror ./t.c --coverage $ ./a.out <- running the exe will generate the coverage data. $ lcov --capture --directory ./ --no-external --rc lcov_branch_coverage=1 --output-file src_coverage.info

I’m not sure if you have the same issue with your actual example, or if this is just an oversight in the testcase you tried to create. I don’t think we should be surprised to see no coverage data, if no code actually runs. Upon what basis would we conclude that something was executed or not?

Your earlier example still looks suspicious in that the path name to your file is “/home/file2.cpp”. Unless your configuration is kind of strange – I would have expected a path of the form “/home/username/file2.cpp” (or some longer path). User source files are not typically found in “/home” – and most normal users will not have permissions to create files there. If lcov is finding that to be your path – then I suspect some inconsistencies in your build/test environment. If you typed the example manually and it isn’t actually what you see – then your example is not really helping to diagnose the issue you face.

Once again: it would be useful to see your actual compile command line and your actual link line. It would also be useful if you checked through the generated .info file to verify whether all the file paths actually exist or not. If the paths do not exist: then we can be pretty sure that you have a build inconsistency or a configuration error.

Henry

[kramer1985]

Hi, I try to use this command line lcov --ignore-errors empty but I alway get this error message: lcov: Error: invalid command line: /usr/local/bin/lcov --directory smp-fcgi-tfs --ignore-errors empty Need one of options -z, -c, -a, -e, -r, -l, --diff or --summary Use lcov --help to get usage information I have no isea how to call lcov --ignore-errors

[henry2cox]

I believe that this issue has been addressed - so I am closing it now.

If there is still a problem, please reopen this issue or file a new one. Please include a detailed description of the problem and, if possible, include a testcase which exhibits the issue.

I am trying to clean up the list of open issues to make it easier to find problems that still need to be addressed. Henry