Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is replaced mid-iteration: use-after-free in PLy_funct

On 25/05/26 19:26, Matheus Alcantara wrote:
> On Fri May 15, 2026 at 8:11 AM -03, PG Bug reporting form wrote:
>> The root cause is that srfstate->savedargs is tied to proc->mcxt (which can
>> be deleted at any per-call boundary) rather than to
>> funcctx->multi_call_memory_ctx (which lives for the entire SRF lifetime).
>>
>> Option A — allocate savedargs in funcctx->multi_call_memory_ctx:
>> Change PLy_function_save_args to accept a MemoryContext parameter and pass
>> funcctx->multi_call_memory_ctx from PLy_exec_function. The saved PyObject*
>> references are valid regardless of which MemoryContext holds the struct.
>>
>> Option B — detect proc rebuild and discard stale savedargs:
>> After PLy_procedure_get returns a new proc, check whether it differs from
>> the
>> proc that created srfstate->savedargs. If so, discard savedargs
>> (PLy_function_drop_args or simply set to NULL) and skip the restore.
>>
> 
> Hi, thank you for the very detailed bug report. I've managed to
> reproduce the issue on master.
> 
> Option A seems to fix the issue (see attached patch) but I've found
> another issue while playing with this that I think it's related:
> 
> ...
> 
> This is because when PLy_procedure_delete() is executed on
> PLy_procedure_get() it also destroy information related with recursive
> functions, such as "calldepth", "argstack" and "globals" which cause the
> assert failure Assert(proc->calldepth > 0) on PLy_global_args_pop() when
> it's executed on PG_CATCH block on PLy_exec_function() or EXC_BAD_ACCESS
> when accessing "argstack" or "globals".
> 
> Although changing the memory context where savedargs is allocated fix
> the reported issue I think that the long term fix is to preserve such
> necessary execution information during PLyProcedure re-creation. I'm
> still studying the code to see if and how this can implemented.
> 

This is being tricky to debug. I'm not being able to reproduce the 
issue with assert disabled, not even with the steps shared on the bug 
report.

Andrzej could you please confirm if you hit this failure with assert 
enable? And if it's enable, could you please check if it's also 
happens with assert disabled?

Also, the 17.10 version was released some weeks ago, can you also test 
against this new minor release?

--
Matheus Alcantara
EDB: https://www.enterprisedb.com