lcov
lcov copied to clipboard
linux-test-project
1.15 release :ERROR: no valid records found in tracefile
Hi guys,
I'm new to use lcov to the project. Now I met a mistake while running lcov in the building, it returns:
lcov: ERROR: no valid records found in tracefile /home/hololqq/git/myoro/test.info
scons: *** [results.xml] Error 255
The lcov is the release version: https://github.com/linux-test-project/lcov/releases/download/v1.15/lcov-1.15.tar.gz But if I use the source code(https://github.com/linux-test-project/lcov/archive/v1.15.tar.gz), this error won't appear. I've compare with the versions, and the only different is the way to get lcov's version. Now I'm confused by this bug.
PS: I ran the project in Ubuntu 18.04, Python 3.6.
I was waiting to see if anyone else would respond. Guess not. The tool is telling you that the file …/test.info is empty (contains no line, branch, or function coverage records).
Is the file empty? Have you perhaps excluded all the code (“// LCOV_EXCL START…STOP”)? Did you filter out all the external code…to leave yourself with nothing?
I’m reasonably confident that the issue is in your testcase setup, not in the ‘lcov’ tool. You might want to try again – and to carefully check the result after each step.
Henry
PS: python version doesn’t matter. Perl version might – but if the lcov script ran, then you probably have a good-enough perl.
I was waiting to see if anyone else would respond. Guess not. The tool is telling you that the file …/test.info is empty (contains no line, branch, or function coverage records). Is the file empty? Have you perhaps excluded all the code (“// LCOV_EXCL START…STOP”)? Did you filter out all the external code…to leave yourself with nothing? I’m reasonably confident that the issue is in your testcase setup, not in the ‘lcov’ tool. You might want to try again – and to carefully check the result after each step. Henry PS: python version doesn’t matter. Perl version might – but if the lcov script ran, then you probably have a good-enough perl.
I've checked the build log of previous version.. Yes this bug existed earlier, it's probably caused by the some codes of my project. With more tests this bug appears in all the versions of lcov.
If there is no coverage data in you ‘test.info’ file: then this is not a bug. The released versions of lcov do not support/do not permit empty trace files. You have to exclude those files from your analysis.
If there is some coverage data in your test.info file: then this probably is a bug.
You haven’t given enough information for me to be able to tell, one way or the other.
There are a couple of ways that ‘lcov –capture’ (or other lcov commands) could legitimately create an empty trace file. A few of these were outlined in my earlier reply.
In my regression flow, we can generate empty intermediate trace files (mostly as an artifact of adaptive scheduling). Thus, I enhanced my version of lcov to support “ignorable errors”. You may want to check that out as well.
Hope this helps.
Henry
e can generate empty intermediate trace files (mostly as an artifact of adaptive scheduling). Thus, I enhanced my ver
OK, Thanks. This sounds very likely. I'll start in this direction.
Hi!
I have ran in this issue intermittently while building inside docker on Windows.
Configuring the project using CMake succeeds and the runs my tests but fails to read the coverage .base file.
100% tests passed, 0 tests failed out of 57
Total Test time (real) = 6.33 sec
Capturing coverage data from .
Found gcov version: 9.3.0
Using intermediate gcov format
Scanning . for .gcda files ...
geninfo: WARNING: no .gcda files found in . - skipping!
Finished .info-file creation
Combining tracefiles.
Reading tracefile xxx_tests_coverage.base
lcov: ERROR: no valid records found in tracefile xxx_tests_coverage.base
libs/xxx/tests/CMakeFiles/xxx_tests_coverage.dir/build.make:76: recipe for target 'libs/xxx/tests/CMakeFiles/xxx_tests_coverage' failed
make[3]: *** [libs/xxx/tests/CMakeFiles/xxx_tests_coverage] Error 255
CMakeFiles/Makefile2:3658: recipe for target 'libs/xxx/tests/CMakeFiles/xxx_tests_coverage.dir/all' failed
make[2]: *** [libs/xxx/tests/CMakeFiles/xxx_tests_coverage.dir/all] Error 2
CMakeFiles/Makefile2:3665: recipe for target 'libs/xxx/tests/CMakeFiles/xxx_tests_coverage.dir/rule' failed
make[1]: *** [libs/xxx/tests/CMakeFiles/xxx_tests_coverage.dir/rule] Error 2
Makefile:1113: recipe for target 'xxx_tests_coverage' failed
make: *** [xxx_tests_coverage] Error 2
Checking the .base file shows its empty:
docker@e63208c7302a:/tmp/workspace/firmware/build$ stat libs/xxx/tests/
CMakeFiles/ Makefile xxx_tests[1]_tests.cmake xxx_tests-d
cmake_install.cmake Testing/ xxx_tests_coverage.base xxx_tests-d-1.0.0
CTestTestfile.cmake xxx_tests[1]_include.cmake xxx_tests_coverage.info xxx_testsVersion.h
docker@e63208c7302a:/tmp/workspace/firmware/build$ stat libs/xxx/tests/xxx_tests_coverage.base
File: libs/xxx/tests/xxx_tests_coverage.base
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 33h/51d Inode: 1970324838191823 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ docker) Gid: ( 1000/ docker)
Access: 2021-02-02 07:53:16.992292500 +0100
Modify: 2021-02-02 07:53:16.992292500 +0100
Change: 2021-02-02 07:53:16.992292500 +0100
Birth: -
This only seems to happen if I build using parallelism, ie. -j cpucores
Writing directory view page.
Overall coverage rate:
lines......: 84.3% (3968 of 4709 lines)
functions..: 73.5% (573 of 780 functions)
Lcov code coverage info report saved in xxx_tests_coverage.info.
Open ./xxx_tests_coverage/index.html in your browser to view the coverage report.
make[3]: warning: Clock skew detected. Your build may be incomplete.
[100%] Built target xxx_tests_coverage
make[2]: warning: Clock skew detected. Your build may be incomplete.
make[1]: warning: Clock skew detected. Your build may be incomplete.
make: warning: Clock skew detected. Your build may be incomplete.
The docker version that I am using copies files between host and vm, which (IIRC) generates hte Clock Skew warnings.
Won’t solve your “why is this file empty” issue – but will solve your “I don’t want lcov to exit” issue:
I added some ‘ignore error’ features to lcov/genhtml some time back. See the code pointed to by pull request #86.
In this case, you would use lcov --ignore-errors empty …[all your other flags] to ignore empty files (warn that the empty file exists – but ignore it). If you want to silence the warning, pass the argument twice: lcov --ignore-errors empty,empty
See the man page (or the source) for more details.
The most common cause of empty data files is when you have excluded all the datapoints – but it sounds like you are seeing a different issue (which may or may not be a bug).
If you can create a repeatable testcase that illustrates the bug – I will try to fix it.
Hope this helps
Henry
After another quick read of your message – a question occurred to me:
Are you running your coverage tests in parallel? That is: there may be more than one executable running at once?
If so: then, unless you have done a bit of additional infrastructure work, your issue is that there is no interlock between the different executable instances when they go to update the GCOV data files when they finish. You are seeing the effect of a simple race.
In our infrastructure, we handle this by telling gcov to use different prefixes and prefix paths. Our regression framework then runs N tests in parallel – each using a different prefix. (We also use a moderately complicated adaptive scheduler to divide tasks between the parallel workers, and to load balance – but you may already have something similar.) At the end of the job – when all the workers are finished – we merge the independent data streams, and generate a report.
Henry
If so: then, unless you have done a bit of additional infrastructure work, your issue is that there is no interlock between the different executable instances when they go to update the GCOV data files when they finish. You are seeing the effect of a simple race.
Never hit such an issue, so went and checked GCC sources (gcc/gcov-io.c:gcov_open()). Looks like this indeed can be a problem on platforms which don't support F_SETLKW ioctl() operation, otherwise it should be fine.
Displaying my ignorance (sorry!): how does this work, with a networked filesystem and multiple hosts? Or is it limited to multiple threads on the same host?
NFS seems to support locking, however man page specifies that locks might misbehave on network issues or administrative changes on remote machine. Other file systems might differ in support and details.
Hi! I am not running the tests in parallell, I am just building it in parallell... something like:
cmake .. && cmake --build . -j 16 && cmake --build . --target xxx_tests_coverage
where xxx_tests_coverage is a custom target defined in https://github.com/bilke/cmake-modules/blob/master/CodeCoverage.cmake
cmake .. && cmake --build . && cmake --build . --target xxx_tests_coverage
strangely works.
Seems like a build issue – flags not passed, something not happening – as opposed to a coverage extraction issue.
At the risk of grasping at straws:
-
Can you do a parallel build (and save all the artifacts), then -
Do a serial build … and compare all the artifacts to the ones you got from the parallel build.
In particular: are the .gc files identical – or not. If not..then the coverage data from gcov is different…and you/we can use that to figure out why (maybe).
Henry
Just checking if this is still an issue - and if you could try again with the current TOT.
I'd like to resolve the issue if we can - or close the issue if we think that it is fixed now.
Henry
Hi, I would like to know where I can write " lcov --ignore-errors empty". Thank you.
Hi, I would like to know where I can write " lcov --ignore-errors empty". Thank you.
If I understand your question: on your 'capture' command line: lcov --capture -o mydata.info --ignore-errors empty -d ...
The option is innocuous in the sense that it won't do anything if there are no empty data files. OTOH: ignoring the error may not be a good idea, if you don't understand why the data file is empty, or do not expect to see empty files. (Debugging/diagnosing the issues may be a Good Idea.)
Note that you will need to be using an lcov version that you download from github: current top of tree, or at least reasonably recent. lcov 'release' versions are too old and do not support the feature.
@henry2cox thank you for your answer, I am going to download lcov-1.15.tar.gz from the link given.
I am going to download lcov-1.15.tar.gz from the link given.
That won't work for the reason mentioned above: 'release' is too old/does not support the feature. You need to clone this repo or download as zip.
I installed the version and I still have this issue: lcov: ERROR: no valid records found in tracefile /home/XXXX/workspace/smp-tfs/.build-ws/lcov/data/init/smp-tfs-lib.info.raw Any help please ?
Trying again. Please read carefully. Another user had exactly the same issue as you: trying to use older lcov versions which did not support some features, unable to figure out how to download and install the TOT code. Please take a close look at the tail of the discussion around issue #204. His solution is your solution.
I am using 1.16 now, and the html are empties. I had a look in your link #204 but nobody answered me yet.
I believe that the suggestion is to download and install the latest lcov implementation - which you appear not to have done. The next suggestion is to describe your environment and testcase in some detail - ideally to provide a small testcase which illustrates the issue. The last suggestion is to consider that you are requesting help from volunteers - not paid priority support. Impatience is not a virtue.
I did not declare my situation as an emergency, I now they are volunteers so there is no way to tell me not paid priority support. Impatience is not a virtue. I will later post more details about my situation.
I believe this issue has been addressed. There have been no additional reports or updates in many months (apart from apparent pilot error/wrong tool version used). As a result: I am closing this issue.
If there is still a problem: please reopen this issue or file a new one.
Please provide a detailed description of the problem you see - ideally, with a small testcase that illustrates the problem.
Henry