Horton

Re: Why our Valgrind reports suck

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-05-09T15:29:43Z
Lists: pgsql-hackers 
Hi,

On 2025-05-08 22:04:06 -0400, Tom Lane wrote:
> A nearby thread [1] reminded me to wonder why we seem to have
> so many false-positive leaks reported by Valgrind these days.
> For example, at exit of a backend that's executed a couple of
> trivial queries, I see
> 
> ==00:00:00:25.515 260013== LEAK SUMMARY:
> ==00:00:00:25.515 260013==    definitely lost: 3,038 bytes in 90 blocks
> ==00:00:00:25.515 260013==    indirectly lost: 4,431 bytes in 61 blocks
> ==00:00:00:25.515 260013==      possibly lost: 390,242 bytes in 852 blocks
> ==00:00:00:25.515 260013==    still reachable: 579,139 bytes in 1,457 blocks
> ==00:00:00:25.515 260013==         suppressed: 0 bytes in 0 blocks
> 
> so about a thousand "leaked" blocks, all but a couple of which
> are false positives --- including nearly all the "definitely"
> leaked ones.
> 
> Some testing and reading of the Valgrind manual [2] turned up a
> number of answers, which mostly boil down to us using very
> Valgrind-unfriendly data structures.  Per [2],
> 
>     There are two ways a block can be reached. The first is with a
>     "start-pointer", i.e. a pointer to the start of the block. The
>     second is with an "interior-pointer", i.e. a pointer to the middle
>     of the block.
> 
>     [ A block is reported as "possibly lost" if ] a chain of one or
>     more pointers to the block has been found, but at least one of the
>     pointers is an interior-pointer.

Huh. We use the memory pool client requests to inform valgrind about memory
contexts. I seem to recall that that "hid" many leak warnings from valgrind. I
wonder if we somehow broke (or weakened) that.

We currently don't reset TopMemoryContext at exit, which, obviously, does
massively increase the number of leaks. But OTOH, without that there's not a
whole lot of value in the leak check...

Greetings,

Andres Freund

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.