Per-thread leak in ECPG's memory.c

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Per-thread leak in ECPG's memory.c
Date: 2026-06-29 13:19:29
Message-ID: CA+hUKGLv202ndx=kP1fZJapNcbfnpq-rezHNyt+cQ4pdxr1akg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

ECPG's auto_mem_destructor() doesn't seem quite right:

1. POSIX thread-specific keys are reset to NULL before their at-exit
destructors are called, so its call to ECPGfree_auto_mem() gets NULL
from get_auto_allocs(), so nothing much happens. It should use the
value passed to the destructor.

2. ECPGfree_auto_mem() doesn't seem to be the right thing to do
anyway, because the user is expected to free heap objects allocated by
the library, for example where
src/interfaces/ecpg/test/thread/alloc.pgc does this:

char **r = NULL;
...
for (i = 1; i <= REPEATS; ++i)
{
EXEC SQL SELECT relname INTO :r FROM pg_class WHERE relname =
'pg_class';
free(r);
r = NULL;
}

With a fix for only problem #1 in place, the thread-exit destructor
double-frees "r" from the final loop. I *think* what is wanted here
is ecpg_clear_auto_mem(), to free just the list structure and not the
values themselves. Draft patch like that attached.

It still leaks on Windows, but that's a known issue and I have a fix
for that as part of a larger refactoring of thread-related stuff, more
on that shortly. This looked like a bug to report separately first.

Hmm, I wonder why ecpg_raise() frees auto-allocated values for all
connections just because one connection raised an error.

Attachment Content-Type Size
0001-ecpg-Fix-auto_mem-cleanup-on-thread-exit.patch text/x-patch 2.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-06-29 13:27:18 Re: FOR PORTION OF should not allow WHERE CURRENT OF
Previous Message Xuneng Zhou 2026-06-29 12:52:51 Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits