I have seen hangs with gcov on Jenkins and locally where the processing just
keeps spinning in an infinite loop. From what I have found out this boils down
to using gcov --all-blocks which is what lcov does with branch coverage enabled.
It is supposed to be fixed in gcc 4.8+ but I see this here with 5.3.1. So its
either a regression or not completely fixed. In any case we will ignore branch
coverage for now. I hoped it would work well but it did only for a while and
having line and function coverage is better than having nothing.
This has been a long standing issue and I finally figured out the details to
get this working. Since we started with coverage there always have been some
problems to get branch coverage work (problems with older gcc versions, lcov
not taking them into account, etc)
The last detail that made me go nuts was that in my lcov version (1.10) there
is a bug which leads to geninfo not applying the config file and thus not
enabling the branch coverage like I defined in the config. I added the
--rc option to work around this case.
In my local run I get this now from lcov-check:
Overall coverage rate:
lines......: 35.5% (65814 of 185169 lines)
functions..: 44.6% (7661 of 17195 functions)
branches...: 22.7% (31492 of 138942 branches)
So we have 22.7% branch coverage right now.
The vivid followers of my QA mails will also see the difference in numbers for
line and function coverage if one comapres my local results and the one on
Jenkins. This is another long standing issue and I need to figure out these
details next. :)
Switch to use a lcov config file which geninfo_auto_base and remove hard coding
the base dir to src/lib. geninfo_auto_base is designed for a use case like
ours where we have several base dirs (lib, bin, tests, ...) and it detects them
automatically. This fixes failures in a coverage run where the file is simply
looked for in the wrong directory.
Stefan Schmidt