lcov error: End line X less than start line

[Vladyyy]

I'm hitting the following error when running lcov I've changed the name of the function since this is a work project.

geninfo: WARNING: ('inconsistent') "test.cpp":1094: function Test::TestClass::foo(unsigned long long, bool*)::{lambda()#2}::operator()() const end line 1093 less than start line
eninfo: WARNING: Use of uninitialized value $line in numeric lt (<)
geninfo: WARNING: Use of uninitialized value $line in concatenation (.) or string
geninfo: WARNING: ('inconsistent') "test.cpp":1094: function Test::TestClass::foo(unsigned long long, bool*)::{lambda()#2}::operator()() const end line  less than start line

Command I'm running

lcov --capture --no-external --ignore-errors inconsistent --directory/gcda_gcno_data --base-directorysrc --output-file /tmp/tmprxm_7j1m -j 0

There is nothing special about the Test::TestClass::foo function, it starts on line 1084 and end on line 1122

Let me know what other debug information would be helpful.

[henry2cox]

It is complaining about the lambda - not the method. From the message, it looks like your compiler hasn't told us what the lambda end line is.

Which compiler and version are you using? Similarly, which lcov version.

If you have a small testcase that illustrates the issue: that is probably the best/easiest.

If not:

1. Rerunning as LCOV_SHOW_LOCATION=1 lcov --capture --no-external .... will give some more information on the 'uninitialized' complaint.
2. Adding --preserve --verbose --rc lcov_tmp_dir=my_temps will tell the tool tell us which file it is processing and were it wrote the temporary (somthing like "my_temps/geninfoxxx/foo.c.gcov.json").

Then we can look at the data for the lambda - and see if there is anything funny about it. The logs will be easier to understand/not interleaved if you remove -j0 (i.e., run serially).

[Vladyyy]

It is complaining about the lambda - not the method.

That's weird because there is no lambda used in the body of this function

I'm using:

gcc --version  

x86_64-pc-linux-gnu-gcc (GCC) 7.5.0
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.

lcov --version

lcov: LCOV version 2.0-1

• I've tried the two methods you suggested: LCOV_SHOW_LOCATION=1 lcov --capture --no-external .... this doesn't show any extra information

• When adding --preserve --verbose --rc lcov_tmp_dir=/tmp/test, I get the geninfoxxx tree structure under /tmp/test but all the dirs are empty

[henry2cox]

Hmm. The LCOV_SHOW_LOCATION ... part should have resulted in location information on the 'uninitialized' message, and the --preserve flag should have told the tool to not remove the intermediate data. I fear that I don't know why they would not work in your environment.

I guess no joy on a testcase.

If you can find 'test.gcda' and 'test.gcno' from your problematic compilation unit 'test.cpp', can you run: $ gcov -c -i path/to/test.gcda -o dirname /path/to/test.gcno and then look at the data for the function in question - as well as the region around it.

I don't have a gcc/7.5.0, so I cannot check - if it does not support "-i", then just remove that flag.

Yet another experiment: gcc/7.5 is pretty old...is there any way for you to try a newer gcc (or llvm) - so we can see if the result is any different?

[henry2cox]

I think I know what is happening. Can you show me the definition for Test::TestClass::foo (the whole thing, including all the contained lambdas). I also need to know the line numbers (so annotated is good, but just the start line number is probably sufficient). Would also be useful to see the corresponding gcov/7.5.0 output. If you would rather not show code to the entire internet - then it isn't hard to deduce either my work or non-work address.

I suspect that this is a bug/an issue fixed in somewhat newer gcc - but I am not 100% certain of that - nor do I know in which version the fix first appeared - if it is indeed fixed. I also think that LLVM doesn't have the issue (for either the gcov or profraw coverage flow).

Forgot to mention: if you want to skip over this issue - either to ignore it entirely, or to debug later - then you can use the --rc derive_funtion_end_line=0 flag to turn off this particular feature and avoid the issue.
This has the side effect of disabling some other features - see the man page for details.

[henry2cox]

One more idea/suggestion for debugging:

• execute lcov --capture --rc derive_function_end_line=0 -o original.info ... This should generate a .info file result (with some missing end lines)
• now execute lcov -o test.info -a original.info We expect to see the same error message as your original report. (This step is simply to prove that the error still happens.)
• munge the output however you like - but preserving line numbers and function name relationships - say, use sed to turn things into 'Class1' , 'Class2', 'method1', 'method2' - but leaving ::(lambda... suffixes (if any exist.). It is likely important to preserve relationships between names, and it is important that the names be syntactically valid (ie.,they could have been generated by the tools). Feel free to set all 'hit' counts to 1 - or we can just claim that you ran only 1 test and the coverage number is not representative of anything.
• rerun lcov -o test.info -a munged.info - to verify that the munged result still exhibits the error behaviour.
• attach munged.info to this report (or send it via another path).

[henry2cox]

FWIW: I tried to write a small example to cause a similar failure - but I haven't been able to make the tool fail. Thus: I probably need your testcase to debug. As described above: what I need is the .info data for 'test.cpp' - ideally, the whole file, but maybe just the data for files and lines between the method just before TestClass::foo and the method just after it (i.e., so 3 methods total). Due to the format of the file - that might be a bit of a pain to extract.

[Vladyyy]

Will provide the info you requested this week.

[henry2cox]

Just a reminder that the info mentioned above is still pending. I think I fixed the issues (locally - not checked in) - but I am not certain as I was unable to reproduce the issue locally - so debugging via inspection. Thanks

[henry2cox]

pushed c2fd3ab016e - which addresses at least one bug related to lambdas, but may or may not be related to the issue you saw. (Still hoping to see the testcase data.)

[henry2cox]

testcase not forthcoming - so closing this issue now, on the assumption that it was fixed.

If there is still a problem, please either reopen this issue or file a new one. Please include a testcase which illustrates the bug, and include detailed instructions for how to reproduce. Thanks Henry