Horton

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

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

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema <postgres@jeltef.nl>
Cc: Michael Paquier <michael@paquier.xyz>, duspensky@ya.ru, pgsql-bugs@lists.postgresql.org
Date: 2021-03-16T17:36:24Z
Lists: pgsql-bugs 
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.

Yeah, after doing some testing locally it seems that the non-error path,
at least, is free of additional problems.  I set up a shell loop to hit
the postmaster with SIGHUP ten times a second.  Looking at v12, an
ssl-enabled postmaster leaks very visibly after a few moments; while
there's no detectable leak in HEAD.  So +1 for back-patching the DH_free
fix.  (Michael, do you want to do the honors?)

> Looking at it again now, I see that if an error occurs when parsing
> ssl_crl_file the root_cert_list is in fact leaked. This was easy to
> reproduce by specifying a bogus path for ssl_crl_file.

Interesting.  While this case doesn't seem likely to pose much of a
practical problem, maybe we should clean it up.  I'd already wondered
what was the point of separating the creation and use of the
root_cert_list by so much --- seems like we could install it
immediately after creation.

			regards, tom lane

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.