Re: Why our Valgrind reports suck

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