From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: wliang@stu.xidian.edu.cn, pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: Report a potential memory leak in setup_config()
In-reply-to: <A7070803-5A15-486E-AE04-ECC13CD10038@yesql.se>
References: <64ee7543.20d.17efb1270ca.Coremail.wliang@stu.xidian.edu.cn>
 <A7070803-5A15-486E-AE04-ECC13CD10038@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Tue, 15 Feb 2022 13:10:45 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3052162.1644942806.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 Feb 2022 11:33:26 -0500
Message-ID: <3052163.1644942806@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3052163.1644942806%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
> On 15 Feb 2022, at 02:49, wliang@stu.xidian.edu.cn wrote:
>> Specifically, at line 1095, function pretty_wal_size() is called, which=
 allocates a chunk of memory by using pg_malloc and returns it. However, t=
he return chunk is directly passed to snprintf as its 3rd parameter. As a =
result, there is a memory leak.

> PostgreSQL isn't all too concerned about small static leaks in short liv=
ed
> programs, like initdb.  Memory will be freed shortly when the program ex=
its.
> Complicating the code to save 28 bytes seems hardly worth it, but if you=
 feel
> strongly about it I suggest proposing a patch to fix it.

Yeah.  A quick run of initdb under valgrind reports

=3D=3D3051337=3D=3D LEAK SUMMARY:
=3D=3D3051337=3D=3D    definitely lost: 893,446 bytes in 47 blocks
=3D=3D3051337=3D=3D    indirectly lost: 4,490 bytes in 51 blocks
=3D=3D3051337=3D=3D      possibly lost: 0 bytes in 0 blocks
=3D=3D3051337=3D=3D    still reachable: 2,403 bytes in 22 blocks
=3D=3D3051337=3D=3D         suppressed: 0 bytes in 0 blocks

It might be worth trying to knock that down a bit, but I wouldn't
start with a one-time leak of 28 bytes.  It looks like the biggest
offender is that we don't bother trying to reclaim the lines
malloc'd by readfile() and replace_token().  Fixing that is *maybe*
worth the trouble, but TBH no one has complained about initdb's
memory consumption.

			regards, tom lane