Re: Coverage with make coverage-html is broken on latest Debian using lcov v2

Hi,

On 2026-10-03 12:39:29 -0400, Tom Lane wrote:
> > I'm not sure sure about the 0002 patch though. It builds in the
> > assumption that lcov is broken and that we're going to ignore these
> > warnings by default [forever]. Do we really want to bake those flags
> > into our build system?
>
> That bothers me too, mainly because I foresee a risk of the switches
> hiding genuine problems somewhere down the road. Also the switches
> Narek proposes don't match what I've found to be necessary on my
> own installation (so maybe there is a gcov version dependency here
> too?).
>
> For the moment I'm content to insert the --ignore-errors flags
> manually. The 0001 patch should at least reduce the noise level
> a bit.

Yea, I think we really need to fix the sources of some of these corruptions. I
don't think it's primarily lcov's problem, I think it's that we end up with
actually corrupted coverage data and that lcov got *better* at surfacing that.

I know of a few problems:

- We build some code without -pthread that is then used in a threaded
environment. One problem is that gcc uses the presence of -pthread to
influence what -fprofile-update=method gets chosen.

Which, I think, means that any multi-threaded execution of any of that code
ends up using the non-atomic counter updates, which allows them to become
inconsistent.

For autoconf we end up with -pthread for libpq, pgbench, and ecpg. But not
for pgport, pgcommon, which means none of them are safe.

For meson it's similar, except that the backend will typically be built with
-pthread as well. But that doesn't help the fact that pgport, pgcommon can
end up being completely inconsistent.

- Sometimes we can interrupt a process in the middle of a normal exit, while
coverage data being written out, with a SIGQUIT/SIGKILL, which then leads to
corrupted coverage files.

Those coverage files then end up being corrupted.

I unfortunately don't know of a way of fixing that short of teaching libgcov
to update the coverage files with an atomic rename - except that it uses
flock for locking, which probably would be incompatible with that :(.

- code compiled multiple times ends triggering errors

That's the new lcov-2.5 thing where it complains about functions being in
different places if they're built multiple times.

I suspect that a lot of those we could fix with relatively minimal effort,
e.g. by moving the #ifdef SH_RAW_ALLOCATOR around SH_CREATE to inside the
argument list and instead of defining use_builtin_flow() in three places
depending on how things are built, do it in one, moving the ifdefs inside.

- flex generates wrong file locations

This has been an open flex bug for a long time:
https://github.com/westes/flex/issues/235

Kinda wonder if we should just strip line numbers from the file. Or perhaps
we should compile with explicit options to not generate a profile?
Unfortunately the lines are only wrong starting with the first rule,
otherwise it'd not be too hard to just fix that.

Until then I guess it might make sense to add --exclude '*.l' or such? That
does seem to avoid these problems.

- The intentional use of SIGQUIT shutdowns in a lot of tests leads to
incomplete coverage

That doesn't trigger gcov / lcov / genhtml errors, but it leads to things
being assumed uncovered that aren't.

Because we shut down a lot of tap test clusters with immediate mode, this
actually has pretty large impact.

I've experimented with replacing all the _exit() uses in the backend with
something that triggers flushing of the coverage information in some cases
that can be considered kinda maybe safe.

I think there are definitely some bugs in lcov around multi-line statements
that contain branches. That's where it seems to very often get confused and
claims the data is inconsistent, but afaict it's due to it misunderstanding
the data that gcov spits out. I'll try to make a bug report out of that.

Greetings,

Andres Freund