Re: BUG #19092: scram_free() will free on address which was not malloc()-ed in pg_scram_mech

> On 21 Oct 2025, at 09:43, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:

> The issue is about the only implementation of pg_fe_sasl_mech interface:
> pg_scram_mech. In the init func of pg_scram_mech, the variable
> state->password is assigned by variable prep_password, which is prepared in
> function pg_saslprep(). However, pg_saslprep() will use palloc/pfree or
> malloc/free determined by FRONTEND marco。If we are in backend env，the
> prep_password will be palloc-ed in CurrentMemoryContext. The problem is
> state->password will be released by free() in the free func of
> pg_scram_mech: scram_free, and will cause 'free on address which was not
> malloc()-ed' error.

Mixing frontend and backend code like that seems to register somewhere on the
"break it and you get to keep both pieces" scale.

> This issue occurred when I was attempting to make a connection to Backend
> via libpq interfaces in Backend itself.

You tried to open a new database connection from a backend by embedding a libpq
client into the backend? Which problem are you trying to solve, maybe there is
an easier way?

--
Daniel Gustafsson