Re: Per-thread leak in ECPG's memory.c

On Mon, 29 Jun 2026 at 14:09, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> 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.

I got curious, and found this in connect.c:

/*
* clear auto_mem structure because some error handling functions might
* access it
*/
ecpg_clear_auto_mem();

If I skip the pgindent commit, the blame gives us this commit:

commit 0c96e42797dbe2918c909209abbaee4d2c985e38
Author: Michael Meskes <meskes(at)postgresql(dot)org>
Date: Wed Nov 8 10:46:47 2006 +0000

Applied patch by Peter Harris to free auto_mem structure on connect

Digging into bug reports from that time, we get:
https://www.postgresql.org/message-id/200611071423.kA7ENpJ1080586%40wwwmaster.postgresql.org

"When using more than one database connection with ECPG, you might have
obtained and freed blocks of data on one connection before trying to open
the other.
If the second connection fails, ECPGraise will be called and call
ECPGfree_auto_mem. This can cause an invalid free() of a pointer you've
already freed."

I couldn't find the actual patch though.

Thom