Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lcov fails with gcc 14 #296

Closed
Klaus33333 opened this issue May 24, 2024 · 2 comments
Closed

lcov fails with gcc 14 #296

Klaus33333 opened this issue May 24, 2024 · 2 comments

Comments

@Klaus33333
Copy link

I tried to run my coverage reports and got the following errors:

lcov --gcov-tool gcov --base-directory . --directory ./build/ --directory ./ -c -o ./build/test_coverage_report.info
Capturing coverage data from ./build/ ./
geninfo cmd: '/usr/bin/geninfo ./build/ ./ --output-filename ./build/test_coverage_report.info --gcov-tool gcov --base-directory . --memory 0'
geninfo: WARNING: Duplicate specification "base-directory|b=s" for option "b"
Found gcov version: 14.1.1
Using intermediate gcov format
Writing temporary data to /tmp/geninfo_datG4GC
Scanning ./build/ for .gcda files ...
Found 31 data files in ./build/

Processing ./build/file1.gcda
geninfo: WARNING: /file1.c:2811: unexecuted block on non-branch line with non-zero hit count. Use "geninfo --rc geninfo_unexecuted_blocks=1 to set count to zero.
Processing ./build/build-utradgw-std-rsysg-nomemdbg-o2-dynamic-cov/test1.gcda
geninfo: WARNING: /usr/include/c++/14/bits/stl_iterator_base_funcs.h:100: unexecuted block on non-branch line with non-zero hit count. Use "geninfo --rc geninfo_unexecuted_blocks=1 to set count to zero.
(use "geninfo --ignore-errors gcov,gcov ..." to suppress this warning)
geninfo: ERROR: mismatched end line for _ZN17TEST1_SUITE1_Test8TestBodyEv at /home/krud/git_my_checkout/rrs/radgw/test1.cpp:9: 9 -> 19
(use "geninfo --ignore-errors mismatch ..." to bypass this error)

I found some similar report in this mailing archive: https://www.mail-archive.com/gcc@gcc.gnu.org/msg101150.html

Do I have any chance of a workaround or even better a fix :-)

Thanks!

@henry2cox
Copy link
Collaborator

I fear that I'm not entirely sure which fixes/workarounds you are looking for.
It appears that we see two different errors/inconsistencies in the gcov data for this testcase:

  1. function _ZN17TEST1_SUITE1_Test8TestBodyEv is found to end on line .../test1.cpp:9 in one GCDA file but is found to end on line 19 in another file.
    This appears to be a bug in gcov (or in gcc) which turns up sometimes (...which is why lcov checks for it).
    lcov uses the function range to figure out which coverpoints belong to the function, in order to support function-level exclusion and also to report covered proportions.
    You can safely ignore the error if you don't care about those features.
    To work around it is a bit painful - as you would have to manually fix the start/end lines (e.g., via sed on the data file)...or possibly someone can fix it in gcc/gcov.

  2. The gcov output data is not consistent at line file1.c:2811.
    I fear that I have forgotten the details, but the comment near line geninfo:2324 suggests that the report will look weird because we will see a block inside some conditional (say, the 'if' clause) such that the 'if' expression is not evaluated but the statement is hit.
    The suggested workaround is to tell geninfo to set the block hit count to zero when that happens (or gcc/gcov need to fix the bug).
    To see how the second issue affects your coverage report: capture your coverage data twice - once setting the count and once without, then generate a differential coverage report (genhtml -o whatTheHeck --baseline-file without.info with.info ...) and inspect the differences.

@henry2cox
Copy link
Collaborator

Closing this issue now.
There appears to be a bug or bugs in gcc/14 (and/or in the corresponding gcov) which causes gcov to generate coverage data which is inconsistent in several ways.
lcov (geninfo) reports about these inconsistencies - and also allows you to ignore them and continue anyway.

If you think that there is still an lcov bug here, please feel free to reopen this issue or file a new one.
Please include a detailed description of the problem and (ideally) include a small testcase which exhibits the issue.
Thanks
Henry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants