Re: BUG #7516: PL/Perl crash

Marko Tiikkaja <pgmail@joh.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