Horton

Re: BUG #16160: Minor memory leak in case of starting postgres server with SSL encryption

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: Jelte Fennema <postgres@jeltef.nl>, Michael Paquier <michael@paquier.xyz>, duspensky@ya.ru, pgsql-bugs@lists.postgresql.org
Date: 2021-03-16T18:12:26Z
Lists: pgsql-bugs 
Hi,

(replying here because Jelte's email doesn't yet seem to have gone
through moderation)

On 2021-03-16 13:36:24 -0400, Tom Lane wrote:
> Jelte Fennema <postgres@jeltef.nl> writes:
> > I'm pretty sure it was the only cause in this specific case. When running
> > postgres with valgrind this was the only block that was repeatedly being
> > leaked.

I wonder if it'd be worth starting to explicitly annotate all the places
that do allocations and are fine with leaking them. E.g. by introducing
malloc_permanently() or such. Right now it's hard to use valgrind et al
to detect leaks because of all the false positives due to such "ok to
leak" allocations.

I sometimes think that we're not great at spotting leak errors because
we're so used to things getting cleaned up in case of error due to
memory contexts...

Greetings,

Andres Freund

Commits

  1. Fix memory leak when rejecting bogus DH parameters.

  2. Fix memory leak when initializing DH parameters in backend

  3. Avoid corner-case memory leak in SSL parameter processing.