From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgmail(at)joh(dot)to |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7516: PL/Perl crash |
Date: | 2012-09-03 16:06:36 |
Message-ID: | 1194.1346688396@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
pgmail(at)joh(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | anjali_524 | 2012-09-03 18:06:49 | Core was generated by `postgres: kazeon KazDB 192.168.50.131(37625) SELECT '. |
Previous Message | pgmail | 2012-09-03 15:23:11 | BUG #7516: PL/Perl crash |