Re: use valgrind --leak-check=yes to detect memory leak

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex <zhihui(dot)fan1213(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: use valgrind --leak-check=yes to detect memory leak
Date: 2019-08-14 14:50:09
Message-ID: 4717.1565794209@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alex <zhihui(dot)fan1213(at)gmail(dot)com> writes:
> I want to use valgrind to detect memory leak issue. Then I run into 2
> problems I want to confirm them here.

> 1. In https://wiki.postgresql.org/wiki/Valgrind, the wiki indicates to
> use '--leak-check=no'

That's just a sample configuration.

> 2. in https://github.com/afiskon/pgscripts/blob/master/valgrind.sh#L55,
> it use 'leak-check=no' as well with the wold "No point to check for memory
> leaks, Valgrind doesn't understand MemoryContexts and stuff"

That info is many years out-of-date. You can do it with USE_VALGRIND,
and sometimes that's helpful, but ...

> Q2: do we check memory leak for some new commits or we can ignore them
> based on we use memory context carefully? If we want to check memory leak
> for some new commits, how to handle the existing memory leak case?

Generally, the philosophy in PG is to not bother with freeing data
explicitly if letting it be reclaimed at context deletion is good enough.
Sometimes that's not good enough, but it is in most places, and for that
reason plain valgrind leak checking is of limited use.

valgrind can be pretty helpful if you're trying to identify the origin
of a serious leak --- the kind that accumulates memory wastage
repetitively over a query, for example. But what you have to do is
look for big leaks and ignore all the minor "leaks".

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuli Khodorkovskiy 2019-08-14 15:01:14 Re: Auxiliary Processes and MyAuxProc
Previous Message Antonin Houska 2019-08-14 14:36:35 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)