'lcov' parser error, bad DA line

[thoni56]

I love cov-mode and thanks for the lcov-parser!

I'm running 2022727.31 in Emacs 26.3 and frequently get the error in the subject.

The line seems to be an ordinary DA: DA:218,0. I can supply the .info if need be, but there might be something else going on.

So some more context.

In my Makefile I create .gcov files for the unittests directly from the .gcda with the means of gcov (previously this was the only way ;-)) and then creates the unittests.info for later combination with other coverage data. Could those processes interfere somehow?

[snogge]

I think I need to see the info file, because I do not get how this can happen. I do not see how the process of creating the info file should affect anything, the info file is just text. You probably already know that you can use the gocv files directly in cov mode, I guess the combined data is important.

[thoni56]

Yes, I've used the .gcov files directly for a long time, I create the info to be able to generate HTML coverage later.

Unknowing of the added lcov-parsing I was surprised that these messages showed up, if they hadn't I would have had no idea that was added ;-)

I just now got

Warning (cov): `lcov' parse error, bad DA line /home/thoni/Utveckling/c-xrefactory/src/unittests.info:590
Warning (cov): `lcov' parse error, bad DA line /home/thoni/Utveckling/c-xrefactory/src/unittests.info:1586
Warning (cov): `lcov' parse error, bad DA line /home/thoni/Utveckling/c-xrefactory/src/unittests.info:3487
Warning (cov): Unable to parse lcov data from /home/thoni/Utveckling/c-xrefactory/src/unittests.info:600: DA
Warning (cov): Unable to parse lcov data from /home/thoni/Utveckling/c-xrefactory/src/unittests.info:1592: D
Warning (cov): `lcov' parse error, bad DA line /home/thoni/Utveckling/c-xrefactory/src/unittests.info:3499
Warning (cov): `lcov' parse error, bad DA line /home/thoni/Utveckling/c-xrefactory/src/unittests.info:49248
Warning (cov): Unable to parse lcov data from /home/thoni/Utveckling/c-xrefactory/src/unittests.info:1582: DA
Warning (cov): Unable to parse lcov data from /home/thoni/Utveckling/c-xrefactory/src/unittests.info:4363: DA
Warning (cov): `lcov' parse error, bad DA line /home/thoni/Utveckling/c-xrefactory/src/unittests.info:6998
Warning (cov): Unable to parse lcov data from /home/thoni/Utveckling/c-xrefactory/src/unittests.info:57034: FNDA

And the strange thing is that the info file is "just" 26k lines. (Hint: look at the last of the warnings) info.zip

Is there a way to turn of either of the parsing strategies?

My cov-coverage-alist is ((".gcov" . gcov)). Shouldn't that include ".info" . lcov to activate the lcov parsing? (BTW The documentation of that variable seems to not be updated...)

[thoni56]

And here's more. I got

Warning (cov): `lcov' parse error, bad DA line /home/thoni/Utveckling/c-xrefactory/src/unittests.info:594
Warning (cov): Unable to parse lcov data from /home/thoni/Utveckling/c-xrefactory/src/unittests.info:2446: D
Warning (cov): Unable to parse lcov data from /home/thoni/Utveckling/c-xrefactory/src/unittests.info:2942: F

Notice the seemingly truncated tags D and F. In the info file these lines contain seemingly correct DA tags. Which is a bit strange since the last warning says F.

To me this smells like a timing issue. The info file, or some other file, has not been completely written when cov gets its hands on it. Although the coverage in the fringe seems to be correct.

[thoni56]

Throwing a lot of info here ;-)

My Makefile does this:

lcov -q -z -d   # Reset all coverage
make gcov     # Create .gcov files directly from .gcda
lcov -q -d . -c -o unittests.info
lcov -q --remove unittests.info <un-interesting files> -o unittests.info

I have commented out both 2nd and 4th lines, and still get the problem.

NOTE: I have 74 .gcda file to collate, which takes (with output to the console) 0.7s.

Running this command manually I can almost see that cov starts processing before lcov announces that it has collected all files. So, yeah, I'd vote for a timing issue.

[thoni56]

Yes, confirmed.

By generating the coverage in a temporary file (not named something with .info) and then, when done, move that file to the proper name, there are no warnings anymore.

My .gcov generation with `gcov *.o´ had nothing to do with the problem.

Still, is there a way to turn either of the parsings off?

[snogge]

The search of coverage data actually uses cov-coverage-file-paths as the starting point. Unless that has been customized it will start by looking in the current dir for a .gcov file, and unless one is found progress through the various functions in that variable. The reason for this is probably (I wasn't involved at this stage) that gcov is just about the only format that has a one-to-one mapping between source file and coverage data file. (And even that is not true, it is just the most common configuration and the only one properly supported by cov.el.)

If you have any source code buffer with cov-mode activated and no matching .gcov file, the cov--locate-lcov function will probably be invoked and find the .info file. That file will have coverage data for all of your c-files that also have .gcov files. Lets just say that the data structures used to keep track of source file to coverage file mapping were not designed to handle this situation :( On top of that, the file watchers used to auto-update coverage information in the source buffers whenever the coverage data file is modified will probably be triggered a lot in this situation. Both when the .gcov and .info files are updated. I think the coverage information displayed in the source code buffer will probably stabilize to the correct values eventually, but I have no doubt that you will see a lot of warnings before then.

Unless you actually need the lcov data, you are probably best served by removing cov--locate-lcov from cov-coverage-file-paths.

[snogge]

So that was a lot of explanation and not a lot of solution. It would be nice to fix the issues described in my last post, but I'm afraid it's not a quick fix as it involves rewriting some of the internals of cov.el. I'll try to write some more detailed issues for this later.

[thoni56]

Thanks for the detailed explanation. It helped me in two ways. One I can see where and why all this happens ;-), and two I can turn off the parsing of the lcov data, since I don't need it for my fringe coverage. (Even though my last trick, delaying creating the info file, has made its way into my Makefile.)

Thanks again.

[snogge]

I guess we can close this issue? I'm not allowed. @AdamNiederer, @thoni56 could either of you do the honors?