Description of problem: The latest update of gcc-9 creted issues when generating code coverage for unit tests. Version-Release number of selected component (if applicable): sh$ rpm -q gcc lcov gcc-9.0.0-0.4.fc30.x86_64 lcov-1.13-5.fc29.noarch How reproducible: Deterministic Steps to Reproduce: 1. echo "const int a = 5; int main(void) { return 1;}" > t.c 2. gcc -Wall -Wextra -Werror ./t.c --coverage 3. lcov -t "result" -o ex_test.info -c -d . 4. lcov -l ex_test.info Actual results: [build@5c6865f4371e tmp]$ echo "const int a = 5; int main(void) { return 1;}" > t.c [build@5c6865f4371e tmp]$ gcc -Wall -Wextra -Werror ./t.c --coverage [build@5c6865f4371e tmp]$ ./a.out [build@5c6865f4371e tmp]$ 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: /tmp/t.gcno: Overlong record at end of file! geninfo: WARNING: gcov did not create any files for /tmp/t.gcda! Finished .info-file creation [build@5c6865f4371e tmp]$ lcov -l ex_test.info Reading tracefile ex_test.info lcov: ERROR: no valid records found in tracefile ex_test.info Expected results: //the same output as with gcc-8 $ echo "const int a = 5; int main(void) { return 1;}" > t.c $ gcc -Wall -Wextra -Werror ./t.c --coverage $ ./a.out $ 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 ================================================== [/tmp/data/gcov/] t.c | 100% 1| 100% 1| - 0 ================================================== Total:| 100% 1| 100% 1| - 0 Additional info: // Content of files. Maybe it will be useful for debugging [build@5c6865f4371e tmp]$ ls a.out ex_test.info 'pL'$'\257' t.c t.gcda t.gcno [build@5c6865f4371e tmp]$ cat 'pL'$'\257' -: 0:Source:t.c -: 0:Graph:/tmp/t.gcno -: 0:Data:/tmp/t.gcda -: 0:Runs:1 function main called 1 returned 100% blocks executed 100% 1: 1:const int a = 5; int main(void) { return 1;} [build@5c6865f4371e tmp]$ hexdump -C t.gcda 00000000 61 64 63 67 52 30 39 41 bf ae a7 7b 00 00 00 a1 |adcgR09A...{....| 00000010 02 00 00 00 01 00 00 00 01 00 00 00 00 00 00 01 |................| 00000020 03 00 00 00 eb 72 70 06 78 b3 57 c3 e8 e9 5d db |.....rp.x.W...].| 00000030 00 00 a1 01 02 00 00 00 01 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 |....| 00000044 [build@5c6865f4371e tmp]$ hexdump -C t.gcno 00000000 6f 6e 63 67 52 30 39 41 bf ae a7 7b 02 00 00 00 |oncgR09A...{....| 00000010 2f 74 6d 70 00 00 00 00 01 00 00 00 00 00 00 01 |/tmp............| 00000020 0d 00 00 00 eb 72 70 06 78 b3 57 c3 e8 e9 5d db |.....rp.x.W...].| 00000030 02 00 00 00 6d 61 69 6e 00 00 00 00 00 00 00 00 |....main........| 00000040 02 00 00 00 2e 2f 74 2e 63 00 00 00 01 00 00 00 |...../t.c.......| 00000050 16 00 00 00 01 00 00 00 00 00 41 01 01 00 00 00 |..........A.....| 00000060 04 00 00 00 00 00 43 01 03 00 00 00 00 00 00 00 |......C.........| 00000070 02 00 00 00 04 00 00 00 00 00 43 01 03 00 00 00 |..........C.....| 00000080 02 00 00 00 03 00 00 00 05 00 00 00 00 00 43 01 |..............C.| 00000090 03 00 00 00 03 00 00 00 01 00 00 00 01 00 00 00 |................| 000000a0 00 00 45 01 08 00 00 00 02 00 00 00 00 00 00 00 |..E.............| 000000b0 02 00 00 00 2e 2f 74 2e 63 00 00 00 01 00 00 00 |...../t.c.......| 000000c0 00 00 00 00 00 00 00 00 |........| 000000c8
Maybe bug is in lcov; but you might have a useful tips what should be changed.
Then lcov needs to be adjusted to parse it. I think the only changes that could affect the format are http://gcc.gnu.org/r264462 and http://gcc.gnu.org/r261189.
I forwarded this report to upstream bug tracker, since I can't resolve this kind of problem myself. I'll pull in any fix that they come up with.
(In reply to Lukas Slebodnik from comment #0) > gcc-9.0.0-0.4.fc30.x86_64 > lcov-1.13-5.fc29.noarch > ... > geninfo: WARNING: /tmp/t.gcno: Overlong record at end of file! > ... > lcov: ERROR: no valid records found in tracefile ex_test.info The same problem with "gcc-9.0.1-0.3.fc30.x86_64" and "lcov-1.13-5.fc29.noarch"
And still applies with: gcc-9.0.1-0.11.fc31.x86_64 lcov-1.13-6.fc30.noarch
Can confirm, updated to F30 yesterday and now get similar error messages: $ lcov -c --no-recursion -d /home/foobar/vcs/libeet/build/x86_debug/src -d /home/foobar/vcs/libeet/build/x86_debug/test -o /home/foobar/vcs/libeet/build/x86_debug/test/coverage.info' err: geninfo: WARNING: /home/foobar/vcs/libeet/build/x86_debug/src/eet_fmpool.c.1.gcno: Overlong record at end of file! Cannot open source file ../../src/eet_fmpool.c geninfo: WARNING: cannot find an entry for ^#^#src#eet_fmpool.c.gcov in .gcno file, skipping file! Software versions: lcov-1.13-6.fc30.noarch gcc-9.1.1-1.fc30.x86_64
https://src.fedoraproject.org/rpms/lcov/pull-request/1
https://bugzilla.redhat.com/show_bug.cgi?id=1713541 would fix this as 1.14 contains the fix for this issue, which is https://github.com/linux-test-project/lcov/commit/a5dd9529f9232b8d901a4d6eb9ae54cae179e5b3
(In reply to Stewart Smith from comment #8) > https://bugzilla.redhat.com/show_bug.cgi?id=1713541 would fix this as 1.14 > contains the fix for this issue, which is > https://github.com/linux-test-project/lcov/commit/ > a5dd9529f9232b8d901a4d6eb9ae54cae179e5b3 AFAIU, 1.1.4 brings only gcc8 support. For gcc9, two more commits are needed (ebfeb3e1 and 75fbae1c), see my PR above.
(In reply to Thomas Moschny from comment #9) > (In reply to Stewart Smith from comment #8) > > https://bugzilla.redhat.com/show_bug.cgi?id=1713541 would fix this as 1.14 > > contains the fix for this issue, which is > > https://github.com/linux-test-project/lcov/commit/ > > a5dd9529f9232b8d901a4d6eb9ae54cae179e5b3 > > AFAIU, 1.1.4 brings only gcc8 support. For gcc9, two more commits are needed > (ebfeb3e1 and 75fbae1c), see my PR above. ahhh, yes. Native GCC is GCC9, but the ppc64 cross toolchain is GCC8 (for some reason they're different). So, for me and my main use case, I just need GCC8 but for everybody who isn't me, gcc9 is probably more applicable :)
FEDORA-2019-ef47f81c74 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ef47f81c74
FEDORA-2019-14c85e08bf has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-14c85e08bf
lcov-1.14-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ef47f81c74
lcov-1.14-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-14c85e08bf
lcov-1.14-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
lcov-1.14-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.