found on line but no corresponding 'line' coverage data point. Cannot derive function end line.

[SteveMobile]

function -[] found on line but no corresponding 'line' coverage data point. Cannot derive function end line. (use "geninfo --ignore-errors inconsistent ..." to bypass this error)

Every time I run it, I encounter this error. And it appears in a different location each time

lcov: LCOV version 2.0-1

[henry2cox]

The errors about function end-line derivation are due to inconsistent data generated by your version of gcc/gcov. You can add the suggested 'ignore' flags or turn off end-line derivation if you like (see the man pages). The location is changing either because the gcov files that are getting parsed are in different orders each time you run, or because you are using the '--parallel' flag - so the order that the files are processed, is not deterministic.

Which version are you using? LCOV has been tested and is known to work with gcc/4.8.5, 5.2.0, 6.2.0, 8.3.0, 10.2.0 and (I think) 12.2.0 - all on some flavor of linux/unix. llvm/11.0.0 and 15.0.7 are also known to work (but are not currently supported through the lcov test framework). Other versions and other platforms may or may not also work.

Contributions which expand the set of supported compilers, compiler versions, and platforms are highly appreciated. Contributions which merely test existing code and say "yeah - this also worked on P using C/V" are also useful. Maybe we need a 'community' page which lists all the platforms, versions, etc. which have been tested and/or which are known to be broken.

Henry

(Posted this to wrong issue initially - sorry)

[laishiekai]

Hi I got the same random error after upgrading from 1.16 to 2.0-1. (Btw why "-1" not ".1"?)

geninfo: ERROR: "/.../xxxx.cpp":0: function __cxx_global_var_init found on line but no corresponding 'line' coverage data point. Cannot derive function end line.

My mac is on Ventura 13.4

gcc version: Apple clang version 14.0.0 (clang-1400.0.29.102) Target: arm64-apple-darwin22.5.0 Thread model: posix

gcov version: Apple LLVM version 14.0.0 (clang-1400.0.29.102) Optimized build. Default target: arm64-apple-darwin22.5.0 Host CPU: apple-a12

[henry2cox]

What happens when you add --ignore-errors inconsistent to your lcov and/or genhtml command line? Or, alternately, add --rc derive_function_end_line=0 to your command line?

Either should tell the tool to ignore the error (or don't look for it in the first place) - and continue. Some features will be disabled without end line data - c'est la vie.

If you want to help debug the issue: add --preserve --debug to the command line and make a note of which file hits the issue...then we can look at the gcov-generated JSON data to see what is wrong. You will need to remove --parallel if you were using it, as we want deterministic ordering. At a guess: some compiler-generated symbols (such as __cxx_global_var_init) have weird data associated with them.

[laishiekai]

After I use --ignore-errors inconsistent, all the errors become warning. If I use --rc derive_function_end_line=0, those errors/warning will be gone.

But then I get this new one. It looks like some meta data were messed up. (The file only have 99 lines) I can bypass by adding the filter, but at this point it seems that I should keep using 1.16 for now. Not sure if these arguments works for both version. (My teammates are still using 1.16)

geninfo: ERROR: unknown line '198' in /..../Logger.cpp: there are only 99 lines in file.
  Use 'geninfo --filter range' to remove out-of-range lines.

Also want to ask a very basic question: what's the relationship between lcov and geninfo? Is it like, lcov will call geninfo internally? Does that mean passing these arguments to lcov, it will forward to geninfo? I checked their manual, not exactly the same though.

[henry2cox]

After I use --ignore-errors inconsistent, all the errors become warning. If I use --rc derive_function_end_line=0, those errors/warning will be gone.

Yes. When we ignore the error, then we continue to derive function end lines - and do not error out when we find inconsistency. When we turn off the feature: we simply don't try to derive end lines and so don't notice the inconsistency.

But then I get this new one. It looks like some meta data were messed up.

Yep. In this case, the combination of llvm and llvm-cov are producing some obviously bogus data. You can filter them out or tell the tool to ignore them. You can also use the --keep-going flag - which tells the tool to ignore all errors and attempt to complete the task. Results may be weird or inconsistent, though.

1.16 did not check for such things - and so did not complain (so the equivalent of ignoring the issues). And no: there are a lot of new features in lcov 2.0. The new flags will not work with the old version.

Also want to ask a very basic question: what's the relationship between lcov and geninfo

lcov is a wrapper tool. For --capture, it basically calls geninfo internally - passing or lightly munging various command line options. lcov also supports a bunch of other actions (such as aggregation) which do not result in it calling geninfo.

[laishiekai]

Do you have a suggested way to rollback to 1.16 using how brew? It seems there is only 2.0 on home brew now.

[henry2cox]

Sorry - no idea. I also would not go backward :-) Just because 1.16 isn't telling you about the issues does not imply that there are no issues. Just that 2.0 is a lot more paranoid - and requires you to explicitly sign off on any issues that it notices.

(If you check my affiliation, you will understand why we want to check things very, very carefully. We are using the tools during verification/validation...and errors can be extremely expensive.)

You might be happier with the --keep-going flag (which you can also set in your lcovrc config file). Then the tool will just ignore everything and go for best effort - which is essentially what 1.16 was doing.

[laishiekai]

Thanks a lot for the quick response. I have a big team so I have to take the update more carefully. For now I use a local formula copied from 1.16 branch to rollback, but will definitely look into the way to update lcov less painfully.

And sorry due to confidential data issue I will not be able to share the debug log with public.

[henry2cox]

I understand. Particularly if you have a large team and are interested in automation - you might want to check the --criteria-script and --annotate-script options - and also possibly to read the paper referred in the README. The upshot is that you can use history to figure out who did what, when, what changed and whether you care - then to automagically move forward safely or notify culprits and wait or back out. I don't have spare resources to do that manually - nor do I want to spend them that way.

[henry2cox]

I'm going to go ahead and close this one - as I think the issue is addressed. The upshot is that this is an error check which is telling you that your compiler-generated coverage data is inconsistent. You then have several choices for what to do next:

1. upgrade to a newer compiler version - which may or may not generate consistent data and thus make the error go away. Of course, you may already be using the newest available compiler and/or your environment might not allow you to change versions - so this option may not be open to you.
2. choose to turn ignore the error (--ignore inconsistent or --keep-going) - and hope that the data inconsistency doesn't cause noticable issues in your overall coverage reports. (This is what you were doing when you were using previous lcov versions - even though you might not have known that this is what you were doing.)
3. choose to turn off function end line derivation (--rc derive_function_end_line=0) - and then not use features which rely on knowing the function extents, while also hoping that the inconsistent data doesn't cause other issues.
4. exclude those functions and/or those files from your coverage analysis

As discussed above: lcov 2.0 does more consistency and correctness checking of the gcov-generated data than earlier lcov versions did. In this case, lcov is not generating inconsistent data: it is reporting that the data generated by your compiler is not consistent. That earlier lcov versions did not do this checking does not mean that your data was consistent - only that the tool did not notice.

In any case: if you think that there is still a problem, please either reopen this issue or file a new one. Please include a detailed description of the problem and (ideally) include a testcase which exhibits the issue. Thenks Henry