Re: BUG #7516: PL/Perl crash - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #7516: PL/Perl crash
Date
Msg-id 1194.1346688396@sss.pgh.pa.us
Whole thread Raw
In response to BUG #7516: PL/Perl crash  (pgmail@joh.to)
Responses Re: BUG #7516: PL/Perl crash  (Marko Tiikkaja <pgmail@joh.to>)
List pgsql-bugs
pgmail@joh.to writes:
> We had a segmentation fault in PostgreSQL 9.1.5 with PL/PerlU.
> ...
> It seems to have happened when a PL/PerlU executed a prepared statement
> which calls another PL/PerlU function.

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?  It looks to me like validate_plperl_function()
for the inner invocation could pull the rug out from under the outer
invocation's prodesc pointer.  Although even granting all that, you'd
have to be quite unlucky to get a crash right there, because free'ing
the prodesc wouldn't ordinarily cause the memory to disappear.  This
might be the wrong theory.  You seem to have debug symbols for that
core dump --- can you tell which of the dereferences in line 3373
caused the crash?

            regards, tom lane

pgsql-bugs by date:

Previous
From: pgmail@joh.to
Date:
Subject: BUG #7516: PL/Perl crash
Next
From: anjali_524
Date:
Subject: Core was generated by `postgres: kazeon KazDB 192.168.50.131(37625) SELECT '.