Horton

Thread

  1. Coverage (lcov) failing with inconsistent error in versions 2.x

    Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-07-01T12:12:35Z

    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], 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] https://www.postgresql.org/message-id/flat/CAHsn6_xCDQWe8_vVFhtFk27_xTdyVV%2BDr0yWzaooBZ6%2B-VH-5w%40mail.gmail.com

--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com

  2. Re: Coverage (lcov) failing with inconsistent error in versions 2.x

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-07-01T12:28:44Z

    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

  3. Re: Coverage (lcov) failing with inconsistent error in versions 2.x

    Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-07-01T14:15:01Z

    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

  4. Re: Coverage (lcov) failing with inconsistent error in versions 2.x

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-07-01T15:22:07Z

    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].

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] https://postgr.es/m/flat/CAJ7c6TN%2BMCh99EZ8YGhXZAdnqvNQYir6E34B_mmcB5KsxCB00A%40mail.gmail.com

  5. Re: Coverage (lcov) failing with inconsistent error in versions 2.x

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-07-01T15:55:48Z

    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

  6. Re: Coverage (lcov) failing with inconsistent error in versions 2.x

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-07-03T20:17:31Z

    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"

  7. Re: Coverage (lcov) failing with inconsistent error in versions 2.x

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-07-06T15:22:23Z

    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

  8. Re: Coverage (lcov) failing with inconsistent error in versions 2.x

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-07-06T18:00:34Z

    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)