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

On Tue, 30 Jun 2026 at 00:24, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Tue, Jun 30, 2026 at 2:31 AM Thom Brown <thom(at)linux(dot)com> wrote:
> > On Mon, 29 Jun 2026 at 14:09, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > > Hmm, I wonder why ecpg_raise() frees auto-allocated values for all
> > > connections just because one connection raised an error.
>
> > 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."
>
> Thanks for finding that. Hmm, OK, but I was wondering about the
> opposite scenario, where you *haven't* freed blocks of data before
> doing something on another connection that frees everything for the
> thread:
>
> EXEC SQL AT con1 SELECT datname INTO :anything FROM pg_database;
> EXEC SQL AT con2 ... something that reaches ecpg_raise() ...
>
> /* Why should "anything" not be accessible, and mine to free(), here? */

I see, yeah, that does seem wrong. So would it just be a matter of
moving ecpg_clear_auto_mem() out of ecpg_do_prologue() and put it into
ecpg_do_epilogue() so that it cleans up at the end of the statement
instead of the start of the next one?

Thom