Error parsing gcov branch information with negative count

[dustinlagoy]

I think this is similar to #570. When running grcov on a fairly large codebase I see the following error:

$ grcov --branch ./main
17:46:15 [ERROR] A panic occurred at src/parser.rs:411: called `Result::unwrap()` on an `Err` value: Error("Unable to parse u64 from -1", line: 1, column: 12387510)

Running gcov manually and inspecting the *gcov.json.gz files the offending entry is:

{
  "branches": [
    {
      "fallthrough": true,
      "count": 783,
      "throw": false
    },
    {
      "fallthrough": false,
      "count": -1,
      "throw": false
    }
  ],
  "count": 782,
  "line_number": 83,
  "unexecuted_block": false,
  "function_name": "_ZN15_CORBA_SequenceIN5Tango8DevErrorEE8allocbufEj"
}

I am using gcov/gcc version 11.3.0 and grcov 0.8.12 (also 0.8.11). Probably this is also a bug in gcov but would a fix like #803 be desired here?

On another note, running grcov with --log-level DEBUG or similar options didn't seem to produce any useful output in this case. I had to do some manual searching to find what file was actually causing the issue.

[marco-c]

We should report this to GCC too, so they can fix it.
In the interim, a workaround to avoid failing sounds fine to me, not sure what -1 should be considered though (should it be considered 0 or >0?).

[calixteman]

@marxin ^^

[marxin]

Yes, please file an upstream GCC bug and attach the corresponding .gcda and .gcno files. Thanks!

[edmundoferreira]

I also faced a similar issue when running on C++ codebase with gcc/clang. After some comparisons with other tools gcovr and lcov I found this issue gcovr/gcovr#583 (comment) which I believe a good description:

1. of the GCC issue and the usage of -fprofile-update=atomic which in my case fixed the issue
2. how gcovr dealt with this issue
3. how lcov dealt with this issue

I think adding more feedback to the user would be great instead of "just" panic on the type conversion. For example show what files are being corrupted, and maybe even suggest flags compiler flags (gcc and clang both have the same flags) like lcov does.

The extra step of changing the negative numbers back to zeros and ignoring the errors seems a bit more invasive.