pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedCoverage with make coverage-html is broken on latest Debian using lcov v2
10+ messages / 4 participants
[nested] [flat]
* Coverage with make coverage-html is broken on latest Debian using lcov v2
@ 2026-04-21 14:36 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 10+ messages in thread
From: Narek Galstyan @ 2026-04-21 14:36 UTC (permalink / raw)
To: pgsql-hackers; +Cc: narekg@berkeley.edu <narekg@berkeley.edu>; ngalstyan4@gmail.com
Hi all,
On Debian 13 (trixie), `make coverage-html` command triggers an lcov
failure.
There have been past reports of this failure in pgsql-hackers here
<https://www.postgresql.org/message-id/202602261231.mlk2icrqrwpw%40alvherre.pgsql;
.
APT package repositories on Debian 13 default to lcov v2 (2.3.1-1) which
is stricter about a few warnings and triggers an error. This commit
<https://github.com/linux-test-project/lcov/commit/5f659f63801ef7f94c50a0eb5cffa1ea70f73651>in
lcov details some of the changes for lcov v2, including the stricter error
handling (see bullet b)).
After applying the attached patches to the current master branch, `make
coverage-html` starts working with lcov v2.
---
More details:
Without applying any of the patches, with --enable-coverage and in-tree
build (no vpath), make check && make coverage-html results in the following
error:
```
/usr/bin/lcov --gcov-tool /usr/bin/gcov -q --no-external -c -i -d . -d . -o
lcov_base.info
lcov: ERROR: (usage) duplicate file ./src/backend/access/table/tableam.gcno
in both . and .
(use "lcov --ignore-errors usage ..." to bypass this error)
Message summary:
1 error message:
usage: 1
make: *** [src/Makefile.global:1064: lcov_base.info] Error 1
```
After applying the first patch, I get this error:
```
genhtml: ERROR: (corrupt) unable to read trace file 'lcov_base.info':
genhtml: ERROR: (inconsistent) "lcov_base.info":507880: duplicate function
'blockreftable_create' starts on line
"/home/admin/postgres/src/include/lib/simplehash.h":450 but previous
definition started on 447 while merging lcov_base.info while loading
lcov_base.info.
(use "genhtml --ignore-errors inconsistent ..." to bypass this
error)
(use "genhtml --ignore-errors corrupt ..." to bypass this error)
make: *** [src/Makefile.global:1055: coverage-html-stamp] Error 1
```
With the other 2 patches also applied, make check && make coverage-html
starts producing proper reports.
I tested `make coverage-html` on Debian 13 with lcov v1 and everything
worked there as well.
Narek
--
Attachments:
[application/octet-stream] 0003-Regenerate-configure-after-make-coverage-html-fixes-.patch (956B, ../../CAHsn6_xCDQWe8_vVFhtFk27_xTdyVV+Dr0yWzaooBZ6+-VH-5w@mail.gmail.com/3-0003-Regenerate-configure-after-make-coverage-html-fixes-.patch)
download | inline diff:
From 3223ed56602ae13f0ca6c6fbf2eea8eebc611379 Mon Sep 17 00:00:00 2001
From: Narek Galstyan <narekg@berkeley.edu>
Date: Sun, 19 Apr 2026 22:11:25 -0400
Subject: [PATCH 3/3] Regenerate configure after make coverage-html fixes for
lcov v2
---
configure | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/configure b/configure
index f66c1054a7a..c0d24bc13ff 100755
--- a/configure
+++ b/configure
@@ -777,6 +777,7 @@ enable_tap_tests
enable_dtrace
DTRACEFLAGS
DTRACE
+LCOV_EXTRA_FLAGS
enable_coverage
GENHTML
LCOV
@@ -3474,6 +3475,11 @@ fi
if test -z "$LCOV"; then
as_fn_error $? "lcov not found" "$LINENO" 5
fi
+lcov_version=$($LCOV --version 2>/dev/null | sed 's/^.* //')
+lcov_major_version=$(echo "$lcov_version" | sed 's/\..*//')
+if test "$lcov_major_version" -ge 2 2>/dev/null; then
+ LCOV_EXTRA_FLAGS="--ignore-errors inconsistent,range"
+fi
if test -z "$GENHTML"; then
for ac_prog in genhtml
do
--
2.50.1 (Apple Git-155)
[application/octet-stream] 0002-Add-minimal-lcov-ignore-errors-flags-to-avoid-make-c.patch (2.3K, ../../CAHsn6_xCDQWe8_vVFhtFk27_xTdyVV+Dr0yWzaooBZ6+-VH-5w@mail.gmail.com/4-0002-Add-minimal-lcov-ignore-errors-flags-to-avoid-make-c.patch)
download | inline diff:
From 47c778d3b8d09f9ec84f0336db6eafda175e63b3 Mon Sep 17 00:00:00 2001
From: Narek Galstyan <narekg@berkeley.edu>
Date: Sun, 19 Apr 2026 22:11:23 -0400
Subject: [PATCH 2/3] Add minimal lcov --ignore-errors flags to avoid `make
coverage-html` failure on lcov v2
Without this change, lcov v2 fails with:
genhtml: ERROR: (corrupt) unable to read trace file 'lcov_base.info':
genhtml: ERROR: (inconsistent) "lcov_base.info":507880: duplicate
function 'blockreftable_create' starts on line
"/home/admin/postgres/src/include/lib/simplehash.h":450 but previous
definition started on 447 while merging lcov_base.info while loading
lcov_base.info.
(use "genhtml --ignore-errors inconsistent ..." to bypass this
error)
(use "genhtml --ignore-errors corrupt ..." to bypass this error)
make: *** [src/Makefile.global:1055: coverage-html-stamp] Error 1
---
configure.ac | 6 ++++++
src/Makefile.global.in | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8d176bd3468..12006b0b4b6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -207,11 +207,17 @@ PGAC_PATH_PROGS(LCOV, lcov)
if test -z "$LCOV"; then
AC_MSG_ERROR([lcov not found])
fi
+lcov_version=$($LCOV --version 2>/dev/null | sed 's/^.* //')
+lcov_major_version=$(echo "$lcov_version" | sed 's/\..*//')
+if test "$lcov_major_version" -ge 2 2>/dev/null; then
+ LCOV_EXTRA_FLAGS="--ignore-errors inconsistent,range"
+fi
PGAC_PATH_PROGS(GENHTML, genhtml)
if test -z "$GENHTML"; then
AC_MSG_ERROR([genhtml not found])
fi])
AC_SUBST(enable_coverage)
+AC_SUBST(LCOV_EXTRA_FLAGS)
#
# DTrace
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index dbd5f9d3c40..e0766325d60 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -1047,7 +1047,7 @@ coverage: $(local_gcda_files:.gcda=.c.gcov)
.PHONY: coverage-html
coverage-html: coverage-html-stamp
-GENHTML_FLAGS = -q --legend
+GENHTML_FLAGS = -q --legend @LCOV_EXTRA_FLAGS@
GENHTML_TITLE = PostgreSQL $(VERSION)
coverage-html-stamp: lcov_base.info lcov_test.info
@@ -1056,7 +1056,7 @@ coverage-html-stamp: lcov_base.info lcov_test.info
touch $@
LCOV += --gcov-tool $(GCOV)
-LCOVFLAGS = -q --no-external
+LCOVFLAGS = -q --no-external @LCOV_EXTRA_FLAGS@
all_gcno_files = $(shell find . -name '*.gcno' -print)
--
2.50.1 (Apple Git-155)
[application/octet-stream] 0001-Fix-lcov-duplicate-directory-error-for-non-vpath-bui.patch (1.7K, ../../CAHsn6_xCDQWe8_vVFhtFk27_xTdyVV+Dr0yWzaooBZ6+-VH-5w@mail.gmail.com/5-0001-Fix-lcov-duplicate-directory-error-for-non-vpath-bui.patch)
download | inline diff:
From 957a51a4dad2c82e0ced61ac5813f87ab6752dd7 Mon Sep 17 00:00:00 2001
From: Narek Galstyan <narekg@berkeley.edu>
Date: Sun, 19 Apr 2026 22:07:03 -0400
Subject: [PATCH 1/3] Fix lcov duplicate directory error for non-vpath builds
Fixes `make coverage-html` target on lcov v2 (default on latest Debian).
Commit c3d9a66024a9 added -d $(srcdir) to the lcov commands to support
vpath builds, but did so unconditionally. For non-vpath (in-tree)
builds, $(srcdir) is ".", resulting in "-d . -d ." which causes lcov to
fail with a duplicate file error.
lcov: ERROR: (usage) duplicate file ./src/pl/plpgsql/src/pl_gram.gcno i
both . and .
(use "lcov --ignore-errors usage ..." to bypass this error)
Message summary:
1 error message:
usage: 1
The fix used the same pattern used in commit 5f340cb30ce2 for the
genhtml --prefix option: only add -d $(srcdir) when vpath_build is yes.
---
src/Makefile.global.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index cef1ad7f87d..dbd5f9d3c40 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -1061,12 +1061,12 @@ LCOVFLAGS = -q --no-external
all_gcno_files = $(shell find . -name '*.gcno' -print)
lcov_base.info: $(all_gcno_files)
- $(LCOV) $(LCOVFLAGS) -c -i -d . -d $(srcdir) -o $@
+ $(LCOV) $(LCOVFLAGS) -c -i -d . $(if $(filter yes,$(vpath_build)),-d $(srcdir)) -o $@
all_gcda_files = $(shell find . -name '*.gcda' -print)
lcov_test.info: $(all_gcda_files)
- $(LCOV) $(LCOVFLAGS) -c -d . -d $(srcdir) -o $@
+ $(LCOV) $(LCOVFLAGS) -c -d . $(if $(filter yes,$(vpath_build)),-d $(srcdir)) -o $@
# hook for clean-up
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
@ 2026-06-15 18:22 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Álvaro Herrera @ 2026-06-15 18:22 UTC (permalink / raw)
To: Narek Galstyan <narek.galstyan@enterprisedb.com>; +Cc: pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
Hi Narek,
On 2026-Apr-21, Narek Galstyan wrote:
> On Debian 13 (trixie), `make coverage-html` command triggers an lcov
> failure.
[...]
> Without applying any of the patches, with --enable-coverage and in-tree
> build (no vpath), make check && make coverage-html results in the following
> error:
>
> ```
> /usr/bin/lcov --gcov-tool /usr/bin/gcov -q --no-external -c -i -d . -d . -o
> lcov_base.info
> lcov: ERROR: (usage) duplicate file ./src/backend/access/table/tableam.gcno
> in both . and .
Handling this part with your 0001 seems reasonable to me. I think we
should backpatch that one.
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?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-10-03 16:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 18:51 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:03 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 10+ messages in thread
From: Tom Lane @ 2026-10-03 16:39 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Narek Galstyan <narek.galstyan@enterprisedb.com>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
[ This thread went quiet, but you reminded me of it in answering
Pierre Forstmann's nearby question ]
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> Handling this part with your 0001 seems reasonable to me. I think we
> should backpatch that one.
Agreed, and it doesn't look like that got done, so I'll go do it now.
> 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.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-10-03 18:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:23 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2026-10-03 18:51 UTC (permalink / raw)
To: Narek Galstyan <narek.galstyan@enterprisedb.com>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
I wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
>> Handling this part with your 0001 seems reasonable to me. I think we
>> should backpatch that one.
> Agreed, and it doesn't look like that got done, so I'll go do it now.
Testing this locally, it initially didn't seem to be doing anything.
But that turns out to be because Red Hat has stuck with lcov 2.0-1,
which does not produce the "duplicate file" error. What it does do
is blindly read every foo.gcda file twice, resulting in counts twice
what they should be :-(. Now I wonder whether pre-2.0 lcov did the
same ... but I don't have an old executable laying about to test with.
I gather that coverage.postgresql.org is running a VPATH build,
because it shows some odd coverage counts as well as even ones.
That's impossible in an in-tree build with this bug, if I've
diagnosed it correctly.
Fix pushed.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 18:51 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-10-03 21:23 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 22:26 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Álvaro Herrera @ 2026-10-03 21:23 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Narek Galstyan <narek.galstyan@enterprisedb.com>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
On 2026-Oct-03, Tom Lane wrote:
> Testing this locally, it initially didn't seem to be doing anything.
> But that turns out to be because Red Hat has stuck with lcov 2.0-1,
> which does not produce the "duplicate file" error. What it does do
> is blindly read every foo.gcda file twice, resulting in counts twice
> what they should be :-(. Now I wonder whether pre-2.0 lcov did the
> same ... but I don't have an old executable laying about to test with.
>
> I gather that coverage.postgresql.org is running a VPATH build,
> because it shows some odd coverage counts as well as even ones.
> That's impossible in an in-tree build with this bug, if I've
> diagnosed it correctly.
Hmm, no, it's running an in-tree build,
./configure --cache-file=/home/coverage/pgsrc/configure.cache --enable-depend --enable-coverage --enable-tap-tests --enable-nls --with-python --with-perl --with-tcl --with-openssl --with-libxml --with-ldap --with-pam --with-llvm --with-lz4 --enable-injection-points CFLAGS=-O0 'CPPFLAGS=-DCOPY_PARSE_PLAN_TREES -DWRITE_READ_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST' LLVM_CONFIG=/usr/bin/llvm-config-19 CLANG=clang-19 >> $LOG 2>&1
So, I was going to say that Debian packages the same version:
coverage@galvin:~$ lcov --version
lcov: LCOV version 2.0-1
but I found out that the packaging files have a patch file that modifies
the version string, so the code that's actually running is 2.3, not 2.0.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142382
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La espina, desde que nace, ya pincha" (Proverbio africano)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 18:51 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:23 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-10-03 22:26 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 10+ messages in thread
From: Tom Lane @ 2026-10-03 22:26 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Narek Galstyan <narek.galstyan@enterprisedb.com>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> So, I was going to say that Debian packages the same version:
> coverage@galvin:~$ lcov --version
> lcov: LCOV version 2.0-1
> but I found out that the packaging files have a patch file that modifies
> the version string, so the code that's actually running is 2.3, not 2.0.
Oy, that's misleading. Hope they fix it soon.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-10-03 21:03 ` Andres Freund <andres@anarazel.de>
2026-10-03 21:32 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 23:07 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Andres Freund <andres@anarazel.de>
1 sibling, 2 replies; 10+ messages in thread
From: Andres Freund @ 2026-10-03 21:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; Narek Galstyan <narek.galstyan@enterprisedb.com>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:03 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Andres Freund <andres@anarazel.de>
@ 2026-10-03 21:32 ` Álvaro Herrera <alvherre@kurilemu.de>
1 sibling, 0 replies; 10+ messages in thread
From: Álvaro Herrera @ 2026-10-03 21:32 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Narek Galstyan <narek.galstyan@enterprisedb.com>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
On 2026-Oct-03, Andres Freund wrote:
> - 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.
We had these threads about this problem
https://postgr.es/m/58ce1068-0cfc-3394-df69-ee0d03aaebb5%402ndquadrant.com
https://postgr.es/m/816a4de5-3f15-4d66-1ec1-791cab2ca6df@gmail.com
but I don't think we did anything about that.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:03 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Andres Freund <andres@anarazel.de>
@ 2026-10-03 23:07 ` Andres Freund <andres@anarazel.de>
2026-10-04 18:16 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 10+ messages in thread
From: Andres Freund @ 2026-10-03 23:07 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; Narek Galstyan <narek.galstyan@enterprisedb.com>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
Hi,
On October 3, 2026 5:03:27 PM EDT, Andres Freund <andres@anarazel.de> wrote:
>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.
Oh, huh. At least one of the two bugs is actually a behavioral difference between gcc versions, not lcov versions. The gcov data starting with gcc 15 reports
var =
cond ? a : b;
i.e. a variable assignment with a conditional in a new line, different than before. And the new output actually triggers errors in lcov back to at least lcov 2.0. It's actually an error in geninfo.
I found another small repro for multi line conditionals where some branches are never reached triggering errors in lcov itself, and that one is not gcc version dependent...
Will report bugs later today or tomorrow, food is more important now.
Greetings,
Andres
--
Sent from my phone. Please excuse my brevity.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Coverage with make coverage-html is broken on latest Debian using lcov v2
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:03 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Andres Freund <andres@anarazel.de>
2026-10-03 23:07 ` Re: Coverage with make coverage-html is broken on latest Debian using lcov v2 Andres Freund <andres@anarazel.de>
@ 2026-10-04 18:16 ` Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 10+ messages in thread
From: Andres Freund @ 2026-10-04 18:16 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; Narek Galstyan <narek.galstyan@enterprisedb.com>; pgsql-hackers@postgresql.org, "narekg@berkeley.edu" <narekg@berkeley.edu>; ngalstyan4@gmail.com
Hi,
On 2026-10-03 19:07:02 -0400, Andres Freund wrote:
> On October 3, 2026 5:03:27 PM EDT, Andres Freund <andres@anarazel.de> wrote:
> >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.
>
> Oh, huh. At least one of the two bugs is actually a behavioral difference between gcc versions, not lcov versions. The gcov data starting with gcc 15 reports
>
> var =
> cond ? a : b;
>
> i.e. a variable assignment with a conditional in a new line, different than before. And the new output actually triggers errors in lcov back to at least lcov 2.0. It's actually an error in geninfo.
>
> I found another small repro for multi line conditionals where some branches are never reached triggering errors in lcov itself, and that one is not gcc version dependent...
>
> Will report bugs later today or tomorrow, food is more important now.
Bug triggering at least with lcov >= 2.0:
https://github.com/linux-test-project/lcov/issues/554
At first I though this was only reachable with gcc 15, but with some LLM help
I found a version that triggered down to gcc 12.
Bug triggering with lcov >= 2.2:
https://github.com/linux-test-project/lcov/issues/555
this seems independent of the gcc version.
It's kinda interesting that both only trigger for multi-line statements.
Which may be related to why we're seeing them more - we use more multi-line
statements than we used to.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-10-04 18:16 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-21 14:36 Coverage with make coverage-html is broken on latest Debian using lcov v2 Narek Galstyan <narek.galstyan@enterprisedb.com>
2026-06-15 18:22 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 16:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 18:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:23 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 22:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-10-03 21:03 ` Andres Freund <andres@anarazel.de>
2026-10-03 21:32 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-10-03 23:07 ` Andres Freund <andres@anarazel.de>
2026-10-04 18:16 ` Andres Freund <andres@anarazel.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox