Coverage (lcov) failing with inconsistent error in versions 2.x
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t248703psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 21, 2026 at 11:53 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t248703_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t248703_1 && git checkout t248703_1Patchset v1 (message #1) is on t248703_1
Hi all
While working on another patch I was suggested to check the coverage of
the tests, but I hit some errors while trying to build the coverage.
The first error and that it's fixed here are:
lcov: ERROR: (inconsistent) "/home/zeus/src/postgresql/src/interfaces/libpq/fe-auth-oauth.c":869: duplicate function 'use_builtin_flow' starts on line "/home/zeus/src/postgresql/src/interfaces/libpq/fe-auth-oauth.c":869 but previous definition started on 991 while capturing from /home/zeus/src/postgresql/build/src/interfaces/libpq/libpq.so.5.19.p/fe-auth-oauth.c.gcno.
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
lcov: ERROR: (inconsistent) "/home/zeus/src/postgresql/worktrees/lcov/src/include/lib/simplehash.h":450: duplicate function 'blockreftable_create' starts on line "/home/zeus/src/postgresql/worktrees/lcov/src/include/lib/simplehash.h":450 but previous definition started on 447 while capturing from /home/zeus/src/postgresql/worktrees/lcov/build/src/common/libpgcommon_srv.a.p/blkreftable.c.gcno.
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
These error are due to duplicated declaration of SH_CREATE() and
use_builtin_flow(), and will only appear in version of lcov >= 2.0
which is the version, but with version 1.16 this doesn't happens.
These failure has already been discussed here[0]/messages/by-id/CAHsn6_xCDQWe8_vVFhtFk27_xTdyVV+Dr0yWzaooBZ6+-VH-5w@mail.gmail.com, but this is a
patch on the code rather than add an exception. That thread still having
some valid points related to another failure that should be discussed
there.
[0]: /messages/by-id/CAHsn6_xCDQWe8_vVFhtFk27_xTdyVV+Dr0yWzaooBZ6+-VH-5w@mail.gmail.com
--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com
On Wed, Jul 1, 2026 at 5:14 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
These failure has already been discussed here[0], but this is a
patch on the code rather than add an exception.
Thanks for the patch!
I'm not sure we should get on the treadmill of catering to lcov, when
I look at the huge number of errors its 2.x line now throws for
widely-used compilers and coding styles. (Right now my ignore_errors
setting is up to six categories, I think. Which is unfortunate, but
its signal-to-noise ratio is just not good right now. Just yesterday I
had to patch out an error in 2.4 that was preventing me from running
genhtml.)
--Jacob
Hi!
Jacob Champion <jacob.champion@enterprisedb.com> writes:
Thanks for the patch!
Thanks for the quick answer!
I'm not sure we should get on the treadmill of catering to lcov, when
I look at the huge number of errors its 2.x line now throws for
widely-used compilers and coding styles. (Right now my ignore_errors
setting is up to six categories, I think. Which is unfortunate, but
its signal-to-noise ratio is just not good right now. Just yesterday I
had to patch out an error in 2.4 that was preventing me from running
genhtml.)--Jacob
Right now with the version that I have for Ubuntu 26.04 (lcov 2.0) I
don't have more issues than the `range` one that I'm trying to confirm
in the other thread if it is or not an issue.
Well, if we're not tracking down all the errors, at least we should try
to keep some fix related to the code that make sense, and for other
errors, probably we should document which version of lcov we support and
the proper .lcovrc file with the errors to ignore so no one have the
same problem in the future?
I don't think anyone will want to add a .lcovrc file to the repository,
but probably a sample file in the documentation will work?
Thanks!
--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com
On Wed, Jul 1, 2026 at 7:15 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
Right now with the version that I have for Ubuntu 26.04 (lcov 2.0) I
don't have more issues than the `range` one that I'm trying to confirm
in the other thread if it is or not an issue.Well, if we're not tracking down all the errors, at least we should try
to keep some fix related to the code that make sense, and for other
errors, probably we should document which version of lcov we support and
the proper .lcovrc file with the errors to ignore so no one have the
same problem in the future?
See also [1]/messages/by-id/flat/CAJ7c6TN+MCh99EZ8YGhXZAdnqvNQYir6E34B_mmcB5KsxCB00A@mail.gmail.com.
I don't have a super strong opinion on documentation. Personally, I'd
be unlikely to commit a patch that tells everyone to start ignoring
the same errors across the board. lcov 2 is just in a weird spot right
now. And you don't have to use lcov/genhtml, and clang/llvm-cov have
their own thing going on, and different compiler versions are clearly
interacting with lcov in different ways...
We could rewrite https://wiki.postgresql.org/wiki/CodeCoverage, maybe.
(As an aside: I want to be careful in how I speak about lcov 2.x. I'm
not an expert in that system, and it's entirely possible that all of
the errors causing it to bail out by default are in fact legitimate
problems in the underlying coverage data that is emitted by a
compiler, rather than bugs in lcov. But I do believe that the current
state of lcov makes it pretty much unfit for purpose with today's
widely-used toolchains and codebases. I'm pretty disappointed in how
v2 is behaving.)
Thanks,
--Jacob
[1]: /messages/by-id/flat/CAJ7c6TN+MCh99EZ8YGhXZAdnqvNQYir6E34B_mmcB5KsxCB00A@mail.gmail.com
Jacob Champion <jacob.champion@enterprisedb.com> writes:
(As an aside: I want to be careful in how I speak about lcov 2.x. I'm
not an expert in that system, and it's entirely possible that all of
the errors causing it to bail out by default are in fact legitimate
problems in the underlying coverage data that is emitted by a
compiler, rather than bugs in lcov. But I do believe that the current
state of lcov makes it pretty much unfit for purpose with today's
widely-used toolchains and codebases. I'm pretty disappointed in how
v2 is behaving.)
Yeah. It seems like lcov 2.0 is kind of okay (it's working for me
anyway), but the later versions are more broken. I'm not excited
about changing our docs to reflect that, and definitely -1 on
changing our code. I think we just have to wait and hope they
get things sorted.
We could rewrite https://wiki.postgresql.org/wiki/CodeCoverage, maybe.
+1, that page seems to be mostly ancient history at present.
regards, tom lane
On 2026-Jul-01, Jacob Champion wrote:
We could rewrite https://wiki.postgresql.org/wiki/CodeCoverage, maybe.
We could rewrite it, yes, but lower effort for me today was to _reread_
it, and in doing so I realized that we disabled branch reporting seven
years ago while we waited for a new GCC version; that fixed GCC version
being now ancient history, I have reenabled branch coverage.
One totally not funny thing is that with that enabled, lcov fails in
even more interesting ways; now you need to give "inconsistent,mismatch"
in LCOVFLAGS. So the whole thing is
make coverage-html LCOVFLAGS="-q -j0 --ignore-errors usage,negative,inconsistent,mismatch" GENHTML_FLAGS="-q -j0 --legend --ignore-errors unmapped,corrupt,inconsistent,range"
I added -j0 to both so that they run parallel processes, which should be
a few second faster. In practice it may make no difference, because the
real time eater is the xid_wraparound test, which lasts for 10 minutes
after all the other tests have completed:
# +++ tap check in src/test/modules/xid_wraparound +++
t/002_limits.pl ............ ok
t/004_notify_freeze.pl ..... ok
t/001_emergency_vacuum.pl .. ok
t/003_wraparounds.pl ....... ok
All tests successful.
Files=4, Tests=23, 415 wallclock secs ( 0.04 usr 0.00 sys + 7.31 cusr 3.81 csys = 11.16 CPU)
Result: PASS
Regards
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"
On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
I added -j0 to both so that they run parallel processes, which should be
a few second faster.
As a heads up, I found that adding parallelism on my local machine ran
it out of memory pretty quickly, with lcov 2.4. YMMV.
Thanks!
--Jacob
On 2026-Jul-06, Jacob Champion wrote:
On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
I added -j0 to both so that they run parallel processes, which should be
a few second faster.As a heads up, I found that adding parallelism on my local machine ran
it out of memory pretty quickly, with lcov 2.4. YMMV.
Strange!
Anyway I noticed that "-j0" doesn't work -- apparently it has to be "-j 0".
I'll see how bad the memory usage gets on the next report, and turn that
off (or set it lower?) if things are too tight.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)
Hello!
Álvaro Herrera <alvherre@kurilemu.de> writes:
On 2026-Jul-06, Jacob Champion wrote:
On Fri, Jul 3, 2026 at 1:17 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
I added -j0 to both so that they run parallel processes, which should be
a few second faster.As a heads up, I found that adding parallelism on my local machine ran
it out of memory pretty quickly, with lcov 2.4. YMMV.Strange!
Anyway I noticed that "-j0" doesn't work -- apparently it has to be "-j 0".
I'll see how bad the memory usage gets on the next report, and turn that
off (or set it lower?) if things are too tight.
I ran into the same issues and I took a different direction, since lcov
wasn't working I started to look for other solutions, turns out that
meson comes with a fallback if lcov is not installed called gcovr, and
works really well, at least for my requirements (not running in the full
stack), without any configuration I have a coverage report, enough at
least.
Has anyone tried gcovr before? I'd be interested to know whether there
are any drawbacks to using it.
Going back to lcov, according to an issue [0]https://github.com/linux-test-project/lcov/issues/473#issuecomment-4492099808, it looks like users are
expected to use the "TOT" version, which makes no sense to me. I tested
the latest lcov release from last week, and I'm still experiencing the
same issues that started this thread.
In conclusion, I'll stick with gcovr for now rather than maintaining an
lcov configuration with many exceptions.
[0]: https://github.com/linux-test-project/lcov/issues/473#issuecomment-4492099808
Regards
--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com
On Tue, Jul 14, 2026 at 4:06 AM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
Has anyone tried gcovr before? I'd be interested to know whether there
are any drawbacks to using it.
I recently tried meson+gcovr and wasn't very happy with the default
merging/filtering of the source and build trees. So I just copy-pasted
the gcovr invocation that meson does and tweaked it to work
correctly... annoying, but less annoying than lcov. (I still need lcov
for differential coverage, though, as far as I can tell.)
--Jacob