Abnormal high line coverage on a function

[JohanBertrand]

Describe the bug
For unknown reasons, there is a part of coverage report than is not working properly on one of my functions.

The line coverage results in 1095216660480 (255 * 2^32) on just a few lines, even if the function is not called.

I am unsure if this is related, but the following warning also occurs during the gcovr call:

(WARNING) Ignoring negative hits in line 'branch  1 taken -1095216660478'.

I do not use any jump instructions. It is just if/else condition within a function.

Moving the function definition to another position in the same file seems to solve the problem for now.

To Reproduce
I sadly do not know how to reproduce this issue. The code is not shareable, and I do not manage to reproduce it in a dummy project yet. I will update this issue if I manage to setup an minimum code example.

Expected behavior
The code coverage should be similar to the second screenshot. The second part of the branch coverage is affected by the error.

Screenshots
Issue:

After moving the code to another place in the same source file:

Desktop:

• OS: ubuntu 22.04
• GCC version 11.4
• GCOVR version 6.0

[Spacetown]

Can you check the coverage files from gcc by running gcov on your own? For me this seems to be also corrupted counters but this can't be detected because they aren't negative.

[Spacetown]

@JohanBertrand Have you checked on this?

[JohanBertrand]

I just checked, and it looks like the .gcda file is corrupted:

    block_info id=0, count=0
    block_info id=1, count=0
    block_info id=2, count=0
    block_info id=3, count=1095216660480
    block_info id=4, count=0
    block_info id=5, count=-1095216660480
    block_info id=6, count=0
    block_info id=7, count=0
    [...]
  line_info=648, count=1095216660480
  line_info=649, count=1095216660480
  line_info=650, count=1095216660480
  line_info=651, count=0
  line_info=652, count=1095216660480
  line_info=653, count=0
  line_info=654, count=0
  line_info=655, count=0
  line_info=656, count=0
  line_info=657, count=0
  line_info=658, count=0
  line_info=659, count=0
  line_info=660, count=-1095216660480
  line_info=661, count=-1095216660480
  line_info=662, count=0
  line_info=663, count=-1095216660480
  line_info=664, count=-1095216660480
  line_info=665, count=0
  line_info=666, count=0
  line_info=667, count=-1095216660480

I guess the issue can be closed then, unless you want to implement something to detect this weird behaviour?

[Spacetown]

We already detect the negative counters but how to detect a big number?
The only thing I can imagine is to have a hardcoded threshold from e.g. 1.000.000.000.000 because I wouldn't expect such a big number in a normal execution and an option to turn the check of.

@latk What do you think about this?

[latk]

I think there is no good way to fix this. This is ultimately not a gcovr bug, but a GCC bug, probably due to using counters that are not concurrency-safe or due to some issue within gcov?

It is not reasonable for gcovr to try to validate gcda files, as that would probably require reconstructing the control flow graph. (Consider a block in the CFG with incoming and outgoing arcs. The sum of counts on outgoing arcs should be equal to (or slightly less than) the sum of counts on incoming arcs. This would not be the case when any count is corrupted.)

We could do something like outlier detection to see if a metric is implausible. Criteria I would suggest:

• The metric is above 2^32 (or some other threshold).

  Rationale: gcovr is mostly used to check test coverage, and tests tend to feature small problem sizes.

• The metric is 4× the next-largest unique metric. In pseudocode: m, m2 = reverse(sorted(unique(metrics)))[:2]; if m > 0 and m2 > 0 and m/m2 > 4: return "invalid".

  Rationale: coverage metrics will be similar to surrounding metrics. For example, if there is an if conditional statement, then the gcda counter for that if would be on the same order of magnitude with the counters for the "true" and "false" branches (maximum 2× difference). Adding a bit of safety margin, and we'd expect few codebases to feature a counter that isn't within a factor of 4 of other counters.

  The worst case is a tight loop like while (n > 1) n = (n/2) * !(n&1) + (3*n + 1) * (n&1); (which should be a branch-free version of the Collatz conjecture). This corresponds to one of the following CFGs, depending on how the compiler structures this:

  flowchart TD
    Start --> If{if n > 1} --> Done
    If --> Body[n = ...] --> If
    Body ~~~ Done
  
    Start2[Start] --> If2{if n > 1} --> Done2[Done]
    If2 --> Body2{n = ...\nif n > 1} --> Body2 & Done2
  

  Loading

  (compare https://godbolt.org/z/GxKMWeYnq and play around with the optimization level)

  However, gcov treats either as only having two blocks with counters: one for initialization, then one for the loop body. If we receive an absurdly high count for the loop body counter, this could be due to a GCC bug – or due to the loop actually needing quite a lot of iteration to check the Collatz conjecture for that input. Gcov counters try to avoid redundant information, so there's no data that could be cross-checked to detect corruption.

  A small difficulty with this approach is that the textual gcov format doesn't give us raw counters, but calculates line and branch coverage from them. The absolute branch coverage metrics would be closest to the original counters. I'd take all available metrics and combine them across different types, as long as we got absolute values and not percentages in the input. This may require adjustments in the parser.

Once we have found metrics that we consider to be invalid or implausible, there's the question about what to do with that insight. Marking those lines as covered or excluded would cause us to report incorrectly high aggregated coverage metrics. Potential approaches:

• Mark the line as excluded, and emit a warning. But this can cause misleading aggregate coverage metrics, and STDERR messages are rarely seen in a CI context.
• Introduce another coverage state. After "covered", "uncovered", and "noncode"/"excluded", there could be the state of "sus".

[Spacetown]

I prefer the first approach because of less complexity. If such a line occur we should set it to 0 if the ignore option is set (like for negative values).

For the CI messages I suggest to add a log handler if a pipeline is detected which supports adding issues by printing the text with a special format,