Horton

Re: Why our Valgrind reports suck

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-05-22T00:32:51Z
Lists: pgsql-hackers 
I wrote:
> Here's a v2 patchset that reaches the goal of zero reported leaks
> in the core regression tests, with some caveats:

Oh, another caveat is that I ran this with a fairly minimalistic set
of build options.  In a more complete build, I observed a small leak
in xml.c, which I posted a fix for in another thread [1].

I also see the leakage Alvaro mentioned with --with-llvm.  I'm not
sure how real that is though, because AFAICS all of it is reported
as "possibly lost", not "definitely lost" or "indirectly lost".
In Valgrind-speak that means there are pointers leading to the
chunk, just not pointing right at its start.  So this could be the
result of allocation tricks being played by the C++ compiler.
The Valgrind manual talks about some heuristics they use to handle
C++ coding patterns, but they don't seem to help in my environment.
In any case, the allocation points are mostly far enough down into
LLVM functions that if the leaks are real, I'd tend to call them
LLVM's bugs not ours.

I haven't really tried our non-core test suites yet.  Out of curiosity
I ran the plperl, plpython, and pltcl suites.  All of them show pretty
enormous amounts of "possibly lost" data, which again seems likely to
be an artifact of allocation games within those libraries rather than
real leaks.  I wonder if they have "valgrind friendly" build options
that we'd need to use to get sane results?

			regards, tom lane

[1] https://www.postgresql.org/message-id/1358967.1747858817%40sss.pgh.pa.us

Commits

  1. Undo thinko in commit e78d1d6d4.

  2. Avoid leakage of zero-length arrays in partition_bounds_copy().

  3. Fix MemoryContextAllocAligned's interaction with Valgrind.

  4. Fix assorted pretty-trivial memory leaks in the backend.

  5. Improve our support for Valgrind's leak tracking.

  6. Reduce leakage during PL/pgSQL function compilation.

  7. Silence Valgrind leakage complaints in more-or-less-hackish ways.

  8. Silence complaints about leaks in PlanCacheComputeResultDesc.

  9. Suppress complaints about leaks in TS dictionary loading.

  10. Suppress complaints about leaks in function cache loading.

  11. Fix per-relation memory leakage in autovacuum.

  12. Fix AlignedAllocRealloc to cope sanely with OOM.