Possible root causes of geninfo 'mismatched end line for main at start.c' ?

[mhoes]

Hi,

While running lcov (capturing initial zero coverage data) I have run into the following error :

geninfo: ERROR: mismatched end line for main at /home/maarten/src/libreoffice/core/desktop/unx/source/start.c:742: 885 -> 742
        (use "geninfo --ignore-errors mismatch ..." to bypass this error)

I get that I can suppress this error and continue, but I was wondering what a possible root causes for this error might be ? Could there be a bug in lcov or gcov, a problem with the codebase that needs to get fixed, or perhaps I am simply doing something wrong here ?

I am running lcov 2.0 on Fedora 40.

Please note I am not a developer (I am just trying to show the developers of the codebase how much of their code gets covered by their test suite). Also, I have successfully run lcov in the past on the same codebase, but that was with both an older version of lcov and an older version of the codebase.

I've included the source file that triggered the error: start.tar.gz

Any and all help is appreciated, and please let me know if I need to supply more information or details.

[henry2cox]

Yes - this looks like a gcc/gcov bug. (You did not mention which version of gcc you are using.)

The specific thing which appears to be happening is that some gcov-generated data file claims that 'main' ends on line 742, whereas some other data file claims that it ends on line 885.
Looking at your source code: the second claim looks more correct :-)

In v2.0 - and in current TOT - if you ignore the error, then the first encounter wins.
In your example: this means that you lose as the first value is the wrong one.
A not-yet-pushed enhancement instead chooses the largest number; that behaviour is (arguably) more correct for your example as well as for some other examples we have encountered.

In the current implementation: function end lines matter only of you happen to be trying to exclude functions by name.

[mhoes]

Thanks for the the help, the given explanation, and the quick reply.

Yes - this looks like a gcc/gcov bug. (You did not mention which version of gcc you are using.)

I am using gcc 14.2.1.

In the current implementation: function end lines matter only of you happen to be trying to exclude functions by name.

So since I am not trying to exclude functions by name, I am now assuming I can safely ignore this (for this particular instance.) I feel I should at least try to not use '--ignore-errors mismatch' immediately and try out '--keep-going' to see if anything else pops up.

Thanks again.

[henry2cox]

I should probably have also said that inconsistent end-line reporting matters only if the particular function(s) you are trying to exclude happen to belong to the mismatch set or are found within the extents of some function in the mismatched set.
Otherwise: you are safe, even in the presence of mismatches.

(The above statement is true today - but may not be true at some point in the future, if somebody thinks of something else to do with end-line information.)

Edited/correction:
The above is slightly misleading, as there are 3 (three) features that rely on function end line information - and thus are not available if end lines are not known and not derived:

• --omit-functions regexp feature: - described above. We need to know the function extents so its content line and branch coverpoints can be removed from the DB.
• --show-proportion feature: we need to know the function extents in order to show and/or to sort them by proportion of their content which is not exercised
• --filter trivial feature: we need to know the extents in order to know whether any particular function meets the 'is_trivial' definition.

All of these features are disabled for those functions whose end line is unknown - and all of these features may go off the rails if the compiler-reported or tool-computed end lines are wrong.

[mhoes]

Just to be thorough, I tried out older gcc/gcov versions than 14.2.1 to see if that changed anything, but I got the exact same result with lcov-2.0 on gcc 13.3.1 (Fedora 39) and gcc 12.3.1 (Fedora 37). Unfortunately, I couldn't try out older gcc versions (gcc 11.3.1, Fedora 35), as the codebase I am experiencing this with requires at least gcc 12 to build.

So if this is indeed a gcc/gcov bug, then it seems to have been there for a few major releases now. (Not sure if this helps or not).

[henry2cox]

Thanks for the update...yeah, I think that the bug has existed for quite some time.
I rather strongly suspect that there are very few tools out there which try to use the information - so it has not mattered that it is incorrect.

For cases that you care deeply about that are wrongly reported, some kind of ugly workarounds are possible.
The easiest (but brittle) option is to simply edit the captured coverage DB to fix the affected end lines (sed is your friend).
This is painful - but is less brittle - but even more painful - if you edit source code to add directives (comments) where they seem necessary.
(I did say that this was ugly.)

[henry2cox]

Conveniently, GitHub will hyperlink this to related issue #116, from long back.
All that is needed is this comment.

[mhoes]

Thanks. Currently I am not looking to exclude any code by function name, and do not use any of the three options (omit-functions|show-proportion|filter trivial) you mentioned. I do use the "--remove" option to remove entire directory's from the resulting tracefile (containing third-party code) though, but that seems safe the way I understand things now.

As far as modifying/fixing the incorrect results go: I guess if it was really required by the developers of the codebase (it isn't currently) - and I felt really energetic - I could add some lines to the shell script I wrote to automate the procedure for them to modify the results using sed, but I very much doubt I could get the developers to start putting gcov specific comments in the codebase. Anyway, currently not a requirement.

For now then I will just add '--ignore-errors mismatch', and see where that gets me.

Well I guess that's it for this issue for the moment; feel free to close it or leave it open as you see fit. Thanks for all the assistance, it's really appreciated.

[henry2cox]

Closing this one now, as the update described above has been pushed.

Feel free to reopen if there is still an issue.