pg_dump memory leak of 400 bytes

From: Oleg Tselebrovskiy <o(dot)tselebrovskiy(at)postgrespro(dot)ru>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pg_dump memory leak of 400 bytes
Date: 2024-12-11 09:59:49
Message-ID: baf1ae4511288e5b421f41e79a3df1a0@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings, everyone!

When I was looking through static analyzer output I've found a memory
leak in pg_dump

In function dumpFunc, when dumping a function with TRANSFORMs, we
allocate
memory for typeids array that contains OIDs of types that need to be
transformed.
The memory is allocated with palloc and is never freed.

Valgrind also confirms this:

1) Create TRANSFORM and FUNCTION using it:
CREATE TRANSFORM FOR int LANGUAGE SQL (FROM SQL WITH FUNCTION
prsd_lextype(internal),
TO SQL WITH FUNCTION int4recv(internal));
CREATE FUNCTION add(int, int) RETURNS int
AS 'select $1 + $2;'
LANGUAGE SQL TRANSFORM FOR TYPE int;

2) Use valgrind to observe the memory leak:
valgrind --leak-check=yes --time-stamp=yes
--error-markers=VALGRINDERROR-BEGIN,VALGRINDERROR-END ./pg_dump -f
somedump.sql
...
==00:00:00:00.764 50282== VALGRINDERROR-BEGIN
==00:00:00:00.764 50282== 400 bytes in 1 blocks are definitely lost in
loss record 92 of 134
==00:00:00:00.764 50282== at 0x4848899: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:00:00.764 50282== by 0x14B758: palloc (fe_memutils.c:107)
==00:00:00:00.764 50282== by 0x120D99: dumpFunc (pg_dump.c:12534)
==00:00:00:00.764 50282== by 0x10F764: main (pg_dump.c:1085)
==00:00:00:00.764 50282==
==00:00:00:00.764 50282== VALGRINDERROR-END
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: definite
fun:malloc
fun:palloc
fun:dumpFunc
fun:main
}
...

Also, we always allocate the same ammount of memory (FUNC_MAX_ARGS *
sizeof(Oid))

I propose two solutions for this problem:
1) Just free the memory in the end of this code block
2) Use static allocation since it is always the same amount

Patches for both variants are attached. I also propose changing palloc
to pg_malloc
since it is the only place in pg_dump where palloc is used instead of
pg_malloc

Oleg Tselebrovskiy, Postgres Pro

Attachment Content-Type Size
v1-0001-pg_dump_memleak.patch text/x-diff 683 bytes
v1-0002-pg_dump_memleak_static.patch text/x-diff 418 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shubham Khanna 2024-12-11 10:05:32 Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.
Previous Message Zhijie Hou (Fujitsu) 2024-12-11 09:45:50 RE: Memory leak in pg_logical_slot_{get,peek}_changes