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
