Re: [PATCH] Memory leak, at src/common/exec.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: Ranier Vilela <ranier_gyn(at)hotmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Memory leak, at src/common/exec.c
Date: 2019-12-16 22:33:16
Message-ID: 27482.1576535596@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
> Please see the man page for putenv. Are you certain it is safe to
> free the string passed to putenv after putenv returns? I think this
> may be implemented differently on various platforms.

POSIX requires the behavior the glibc man page describes:

The putenv() function shall use the string argument to set environment
variable values. The string argument should point to a string of the
form "name=value". The putenv() function shall make the value of
the environment variable name equal to value by altering an existing
variable or creating a new one. In either case, the string pointed to
by string shall become part of the environment, so altering the string
shall change the environment.

So yeah, that patch is completely wrong. It might've survived light
testing with non-debug versions of malloc/free, but under any sort
of load the environment variable would become corrupted. The reason
for the strdup in our code is exactly to make a long-lived string
that can safely be given to putenv.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2019-12-16 22:44:21 RE: [PATCH] Memory leak, at src/common/exec.c
Previous Message Tomas Vondra 2019-12-16 21:53:14 Re: ERROR: could not resize shared memory segment...No space left on device