gcc 8 creates gcno files that are unreadable by lcov #38

berrange · 2018-03-06T13:48:28Z

If a *.c file only contains some global constant the gcno file produced by the --coverage option is not readable by lcov

eg using gcc-8.0.1-0.16.fc29.x86_64 (forthcoming GCC 8 release currently in Fedora 29 rawhide)

[build@localhost tmp]$ cat t.c
const int a = 5;
[build@localhost tmp]$ gcc -Wall -Wextra -Werror -c ./t.c --coverage
[build@localhost tmp]$ lcov --capture --initial --directory .
Capturing coverage data from .
Found gcov version: 8.0.1
Scanning . for .gcno files ...
Found 2 graph files in .
Processing t.gcno
geninfo: ERROR: /tmp/t.gcno: reached unexpected end of file

The same works as expected with gcc-7.3.1-2.fc27.x86_64 on Fedora 27:

[sbose@p50 y]$ cat t.c
const int a = 5;
[sbose@p50 y]$ gcc -Wall -Wextra -Werror --coverage -c t.c
[sbose@p50 y]$ lcov --capture --initial --directory .
Capturing coverage data from .
Found gcov version: 7.3.1
Scanning . for .gcno files ...
Found 1 graph files in .
Processing t.gcno
TN:
Finished .info-file creation

Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=1552042

oberpar · 2018-03-07T13:31:22Z

Thanks for reporting. The issue actually appears to occur for any kind of source code compiled with GCC 8. I've added commit a5dd952 to address the changes introduced with GCC 8. Could you verify if this fixes the problem you are seeing?

berrange · 2018-03-07T14:08:01Z

I confirm that works for the simple demo program I was given by the original bug reporter. So that's good enough for me until someone complains about something else :-)

marxin · 2018-03-07T14:20:13Z

As being developer of GCOV in GCC, I would recommend to use intermediate format (-i) of gcov tool instead of reading of *.gc{da,no} files. Thanks for understanding.

oberpar · 2018-03-07T16:50:36Z

@marxin: GCOV's intermediate format looks promising. Can it be used to generate zero coverage data for .gcno files where no .gcda file is present? This is relevant for example for projects which consist of multiple executables, to get a total coverage view independent of the number of executables actually run during a test.

Some additional thoughts/observations:

Adding the base directory path (current directory at the time of compilation) as a separate field to the output would be of massive value as it would make it easier to recreate absolute source code paths from relative paths.
An option to have output on standard output instead of file would be nice (no more file operation/conflict in case of parallel processing)
If the intermediate file format is intended for consumption by programs, additions to the format should be done in a backwards compatible way (counter example: addition of end_line_number to function data for example would have broken parsing relying on 3 CSV fields per line)
Not sure if this occurs on upstream GCC, but I just noticed that running gcov -iab causes a core dump on GCC 7.2 (7.2.1 20170915 (Red Hat 7.2.1-2)). Using gcov -i alone on GCC 8 throws an assertion (8.0.1 20180222 (Red Hat 8.0.1-0.16)).

marxin · 2018-03-13T12:25:56Z

Thanks for the ideas, I've just created: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846 which I will implement in next GCC release (9.1).

Not sure if this occurs on upstream GCC, but I just noticed that running gcov -iab causes a core dump on GCC 7.2 (7.2.1 20170915 (Red Hat 7.2.1-2)). Using gcov -i alone on GCC 8 throws an assertion (8.0.1 20180222 (Red Hat 8.0.1-0.16)).

Can you please provide an example of a source file that causes that?

oberpar · 2018-03-15T11:42:14Z

Excellent! Looking forward to those gcov improvements.
Regarding the gcc 7 segmentation fault: it appears to occur with any kind of source file:

$ gcc --version
gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ echo "int main() { return 0; }" > t.c
$ gcc t.c -o t --coverage
$ ./t
$ gcov -iab t.c
File 't.c'
Lines executed:100.00% of 1
No branches
No calls
Creating 't.c.gcov'
Segmentation fault (core dumped)

Edit: this is on s390x (big-endian) if that makes a difference.

marxin · 2018-03-15T12:19:40Z

Thanks again, useful feedback. I've just created:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84879

PetterS · 2018-05-02T19:22:46Z

This is great. Thanks! Will there be a new version released with this fix?

oberpar · 2018-05-07T12:55:19Z

It makes sense to release a new version of LCOV including this and other fixes. I'll have to see when I get the time to create it.

marxin · 2018-05-08T16:41:09Z

The GCC 8.1 has been released. A new version of LCOV would be great.

Things worked for compilation as they stood. When running an lcov command lots of warning messages like the following were generated: geninfo: WARNING: cannot find an entry for #usr#local#include#c++#8.1.0#ext#alloc_traits.h.gcov in .gcno file, skipping file! geninfo: WARNING: cannot find an entry for #usr#local#include#c++#8.1.0#ext#atomicity.h.gcov in .gcno file, skipping file! geninfo: WARNING: cannot find an entry for #usr#local#include#c++#8.1.0#ext#new_allocator.h.gcov in .gcno file, skipping file! The solution was not to change user setup as suggested in previous commit. It seems that lcov has great difficulty in handling gcc version 8 output. The gcc base image I use moved to v8 as the latest a few days ago. Fix out gcc base image as gcc:7 until the lcov bug is updated and a packaged released with the fix into Debian. lcov bug: linux-test-project/lcov#38 Which depends on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846

JKorbelRA · 2018-05-16T11:06:17Z

@oberpar, you've saved my day, thanks!

marxin · 2018-05-18T11:37:39Z

@marxin: GCOV's intermediate format looks promising. Can it be used to generate zero coverage data for .gcno files where no .gcda file is present? This is relevant for example for projects which consist of multiple executables, to get a total coverage view independent of the number of executables actually run during a test.

@oberpar This works now:

$ gcc --version
gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc empty.c --coverage && ./a.out ; rm empty.gcda && gcov empty.c && cat empty.c.gcov
empty.gcda:cannot open data file, assuming not executed
File 'empty.c'
Lines executed:0.00% of 10
Creating 'empty.c.gcov'

        -:    0:Source:empty.c
        -:    0:Graph:empty.gcno
        -:    0:Data:-
        -:    0:Runs:0
        -:    0:Programs:0
    #####:    1:int foo(int argc)
        -:    2:{
    #####:    3:  if (argc % 2)
    #####:    4:    return 1;
        -:    5:  else
    #####:    6:    return 2;
        -:    7:}
        -:    8:  
        -:    9:int
    #####:   10:main(int argc, char **argv)
        -:   11:{
    #####:   12:  if (argc == 123)
    #####:   13:    __builtin_abort ();
    #####:   14:  else if(argc != 1111)
    #####:   15:    return foo (argc);
        -:   16:
    #####:   17:  return 0;
        -:   18:}
$ gcc empty.c --coverage && ./a.out ; rm empty.gcda && gcov -i empty.c && cat empty.c.gcov
empty.gcda:cannot open data file, assuming not executed
File 'empty.c'
Lines executed:0.00% of 10
Creating 'empty.c.gcov'

file:empty.c
function:1,0,foo
function:10,0,main
lcount:1,0
lcount:3,0
lcount:4,0
lcount:6,0
lcount:10,0
lcount:12,0
lcount:13,0
lcount:14,0
lcount:15,0
lcount:17,0

marxin · 2018-05-18T13:13:37Z

Adding the base directory path (current directory at the time of compilation) as a separate field to the output would be of massive value as it would make it easier to recreate absolute source code paths from relative paths.

Implemented in current trunk:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846

An option to have output on standard output instead of file would be nice (no more file operation/conflict in case of parallel processing)

Likewise.

If the intermediate file format is intended for consumption by programs, additions to the format should be done in a backwards compatible way (counter example: addition of end_line_number to function data for example would have broken parsing relying on 3 CSV fields per line)

This should be done at consumer's side. Now we provide version which tools should follow and adjust parsing in a corresponding way.

Thus all feature requests mentioned in this issue are done at GCC's side.

oberpar · 2018-05-22T10:35:26Z

@marxin: Excellent, thank you! This should provide a path for LCOV to no longer require parsing of binary .gcno files in the future. Intermediate file support is now at the top of my list for lcov enhancements to work on, though at this time I cannot yet provide a time frame for when it will be done.

marxin · 2018-05-22T10:44:16Z

Don't hurry, you have the whole year before GCC 9.1 will be released ;) If you see any feature requests that will be handy, don't hesitate and create a PR:
https://gcc.gnu.org/bugzilla/

iirina · 2018-09-06T18:12:02Z

@oberpar Is this the right issue to follow for progress on lcov supporting gcov intermediate file format?

oberpar · 2018-09-14T07:42:30Z

@iirina No, I don't think so. This issue is closed and it was about a different problem that only touched on the subject of intermediate files as a side note. That said, there has not been any progress on intermediate file support in lcov so far on my side. Code contributions in that direction are of course always welcome.

Gcc version 8.0.2 produces coverage reports that are not readable by lcov(linux-test-project/lcov#38) As a result we are required to downgrade the gcc-toolchain Download older gcc version from http://repo.msys2.org/mingw/x86_64/ Disable optimizations flags for better coverage reports

Zitrax · 2018-12-29T21:25:36Z

@oberpar How does it look regarding a release? 1.13 is over 2 years old now and newer distros are defaulting to gcc 8 (although I think for example ubuntu has manually included this patch on top of 1.13).

Farwaykorse · 2019-01-04T14:30:04Z

With @Zitrax.
Lcov works only with GCC-8 using the Ubuntu version: 1.13-4, but only available on cosmic (18.10) and disco (devel). (packages.ubuntu.com)

oberpar · 2019-01-07T12:57:03Z

@oberpar How does it look regarding a release? 1.13 is over 2 years old now and newer distros are defaulting to gcc 8 (although I think for example ubuntu has manually included this patch on top of 1.13).

I'm planning for a release in February (2019). Ideally this will include the intermediate file format support that I've started working on.

marxin · 2019-01-07T14:06:52Z

I would like to mention that as written in #43, GCOV intermediate format will change in GCC 9.1 into a JSON-based format. I would consider implementing the new one and use current output for older versions of GCC.

oberpar · 2019-01-07T14:24:28Z

I would like to mention that as written in #43, GCOV intermediate format will change in GCC 9.1 into a JSON-based format. I would consider implementing the new one and use current output for older versions of GCC.

Yes, I am aware of that. I checked all intermediate file format implementations in gcov starting from GCC 5 to 9 and found that even pre-9, the fact that gcov can be run in any directory when using the intermediate format can be leveraged to implement parallel lcov processing even with older versions of GCC. I'm currently planning to start with support for the old format, and add the GCC 9 format after that.

marxin · 2019-01-08T15:03:51Z

Yes, I am aware of that. I checked all intermediate file format implementations in gcov starting from GCC 5 to 9 and found that even pre-9, the fact that gcov can be run in any directory when using the intermediate format can be leveraged to implement parallel lcov processing even with older versions of GCC. I'm currently planning to start with support for the old format, and add the GCC 9 format after that.

Great, maybe you would be interested in newly created wrapper that can help you:
https://github.com/RPGillespie6/fastcov

This fixes bug: linux-test-project/lcov#38

Gcc version 8.0.2 produces coverage reports that are not readable by lcov(linux-test-project/lcov#38) As a result we are required to downgrade the gcc-toolchain Download older gcc version from http://repo.msys2.org/mingw/x86_64/ Disable optimizations flags for better coverage reports

berrange closed this as completed Mar 7, 2018

spencerwuwu mentioned this issue Aug 17, 2018

No such file or directory: '../afl_out/cov/lcov/trace.lcov_info_final' mrash/afl-cov#31

Open

marxin mentioned this issue Sep 27, 2018

Support GCOV intermediate format #43

Closed

milljm added a commit to milljm/package_builder that referenced this issue Apr 24, 2019

Adding a fix for lcov/gcc8

d87780c

This fixes bug: linux-test-project/lcov#38

milljm mentioned this issue Apr 24, 2019

Adding a fix for lcov/gcc8 idaholab/package_builder#198

Merged

nikic mentioned this issue Sep 25, 2019

Fix GCOV not working for PHP-7.4 and master branches php/php-src#4739

Closed

RPGillespie6 mentioned this issue Mar 24, 2021

KeyError: 'current_working_directory' RPGillespie6/fastcov#69

Closed

tomdele mentioned this issue Mar 29, 2021

Adding C++ tests BlueBrain/MorphIO#263

Merged

MaskRay mentioned this issue Jan 1, 2025

[gcov] Set current_working_directory to . for GCC>=9 llvm/llvm-project#121420

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gcc 8 creates gcno files that are unreadable by lcov #38

gcc 8 creates gcno files that are unreadable by lcov #38

berrange commented Mar 6, 2018

oberpar commented Mar 7, 2018

berrange commented Mar 7, 2018

marxin commented Mar 7, 2018

oberpar commented Mar 7, 2018

marxin commented Mar 13, 2018

oberpar commented Mar 15, 2018 •

edited

Loading

marxin commented Mar 15, 2018

PetterS commented May 2, 2018

oberpar commented May 7, 2018

marxin commented May 8, 2018

JKorbelRA commented May 16, 2018

marxin commented May 18, 2018

marxin commented May 18, 2018

oberpar commented May 22, 2018

marxin commented May 22, 2018

iirina commented Sep 6, 2018

oberpar commented Sep 14, 2018

Zitrax commented Dec 29, 2018

Farwaykorse commented Jan 4, 2019

oberpar commented Jan 7, 2019

marxin commented Jan 7, 2019

oberpar commented Jan 7, 2019

marxin commented Jan 8, 2019

gcc 8 creates gcno files that are unreadable by lcov #38

gcc 8 creates gcno files that are unreadable by lcov #38

Comments

berrange commented Mar 6, 2018

oberpar commented Mar 7, 2018

berrange commented Mar 7, 2018

marxin commented Mar 7, 2018

oberpar commented Mar 7, 2018

marxin commented Mar 13, 2018

oberpar commented Mar 15, 2018 • edited Loading

marxin commented Mar 15, 2018

PetterS commented May 2, 2018

oberpar commented May 7, 2018

marxin commented May 8, 2018

JKorbelRA commented May 16, 2018

marxin commented May 18, 2018

marxin commented May 18, 2018

oberpar commented May 22, 2018

marxin commented May 22, 2018

iirina commented Sep 6, 2018

oberpar commented Sep 14, 2018

Zitrax commented Dec 29, 2018

Farwaykorse commented Jan 4, 2019

oberpar commented Jan 7, 2019

marxin commented Jan 7, 2019

oberpar commented Jan 7, 2019

marxin commented Jan 8, 2019

oberpar commented Mar 15, 2018 •

edited

Loading