Re: BUG #7516: PL/Perl crash

Marko Tiikkaja <pgmail(at)joh(dot)to> writes:
> On 03/09/2012 18:06, Tom Lane wrote:
>> Hm. Is it possible that the prepared statement recursively called the
>> *same* plperl function? And that somebody did a CREATE OR REPLACE on
>> that function meanwhile?

> No, that doesn't seem possible in this case. The function calls some
> prepared statements repeatedly, but no recursion should occur.

Hm. Well, I can definitely reproduce a segfault using this example:

CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS $$
spi_exec_query('CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS \'return $_[0] * 3;\' LANGUAGE plperl;');
spi_exec_query('select self_modify(42) AS a');
return $_[0] * 2;
$$ LANGUAGE plperl;

select self_modify(42);

The crash is 100% reproducible if you tweak plperl like this:

diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index bfa805d..307874c 100644
--- a/src/pl/plperl/plperl.c
+++ b/src/pl/plperl/plperl.c
@@ -2393,7 +2393,7 @@ validate_plperl_function(plperl_proc_ptr *proc_ptr, HeapTu
activate_interpreter(oldinterp);
}
free(prodesc->proname);
- free(prodesc);
+ memset(prodesc, 0, sizeof(plperl_proc_desc));
}

return false;

Without that it's probabilistic, since the subsequent malloc in
compile_plperl_function is likely to realloc the exact same space.

So I think we need to institute a reference counting scheme for
the plperl_proc_desc records ...

regards, tom lane