Thread: plperlu function caused a segmentation fault
I was just testing a simple plperlu function to return the existence
of a directory and as soon I pasted the function into psql and hit
Enter, I got the following crash:
CREATE OR REPLACE FUNCTION does_directory_exist(p_path_and_directory
TEXT, OUT does_it_exist TEXT)
RETURNS TEXT AS
$BODY$
my $path_and_directory = shift(@_);
my $does_it_exist = 'false';
if ( -d "$path_and_directory" ) {
$does_it_exist = "true";
}
return "$does_it_exist";
$BODY$ LANGUAGE plperlu VOLATILE COST 100 SECURITY DEFINER;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
Excerpt from the log
2011-08-24 08:55:57 PDT [25795]: [448-1] (user=) (rhost=) LOG: server
process (PID 9474) was terminated by signal 11: Segmentation fault
2011-08-24 08:55:57 PDT [25795]: [449-1] (user=) (rhost=) LOG:
terminating any other active server processes
2011-08-24 08:55:57 PDT [10309]: [21-1] (user=nbaffnet)
(rhost=192.168.96.183) WARNING: terminating connection because of
crash of another server process
2011-08-24 08:55:57 PDT [10309]: [22-1] (user=nbaffnet)
(rhost=192.168.96.183) DETAIL: The postmaster has commanded this
server process to roll back the current transaction and exit, because
another server process exited abnormally and possibly corrupted shared
memory.
2011-08-24 08:55:57 PDT [10309]: [23-1] (user=nbaffnet)
(rhost=192.168.96.183) HINT: In a moment you should be able to
reconnect to the database and repeat your command.
...
2011-08-24 08:55:58 PDT [25795]: [451-1] (user=) (rhost=) LOG: all
server processes terminated; reinitializing
2011-08-24 08:56:00 PDT [14436]: [1-1] (user=nbaffnet)
(rhost=192.168.96.202) FATAL: the database system is in recovery mode
2011-08-24 08:56:00 PDT [14437]: [1-1] (user=postgres) (rhost=[local])
FATAL: the database system is in recovery mode
2011-08-24 08:56:00 PDT [14441]: [1-1] (user=nbaffnet)
(rhost=192.168.96.201) FATAL: the database system is in recovery mode
2011-08-24 08:56:00 PDT [14447]: [1-1] (user=nbaffnet)
(rhost=192.168.96.200) FATAL: the database system is in recovery mode
2011-08-24 08:56:00 PDT [14446]: [1-1] (user=nbaffnet)
(rhost=192.168.96.200) FATAL: the database system is in recovery mode
2011-08-24 08:56:00 PDT [14435]: [1-1] (user=) (rhost=) LOG: database
system was interrupted; last known up at 2011-08-24 08:55:13 PDT
2011-08-24 08:56:00 PDT [14435]: [2-1] (user=) (rhost=) LOG: database
system was not properly shut down; automatic recovery in progress
2011-08-24 08:56:00 PDT [14435]: [3-1] (user=) (rhost=) LOG:
consistent recovery state reached at 3A3B/CCFBD7C8
2011-08-24 08:56:00 PDT [14435]: [4-1] (user=) (rhost=) LOG: redo
starts at 3A3B/C7321A10
...
select * from pg_language ;
lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid |
laninline | lanvalidator | lanacl
----------+----------+---------+--------------+---------------+-----------+--------------+--------
internal | 10 | f | f | 0 |
0 | 2246 |
c | 10 | f | f | 0 |
0 | 2247 |
sql | 10 | f | t | 0 |
0 | 2248 |
plperl | 10 | t | t | 16545 |
16546 | 16547 |
plperlu | 10 | t | f | 16545 |
16546 | 16547 |
plpgsql | 10 | t | t | 11571 |
11572 | 11573 |
(6 rows)
select version();
version
-------------------------------------------------------------------------------------------------------------------
PostgreSQL 9.0.2 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit
Are there any known bugs with plperlu and 9.0.2? I did a quick search
of the archives and the only somewhat-relevant report I could find was
http://markmail.org/message/iib5eu7qgtazaorg
bricklen <bricklen@gmail.com> writes: > I was just testing a simple plperlu function to return the existence > of a directory and as soon I pasted the function into psql and hit > Enter, I got the following crash: FWIW, this function seems to work fine for me in 9.0.4 on a Fedora 14 x86_64 box ... and there haven't been any bug fixes in plperl since 9.0.2, except for this one http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=cb252c2acd415d304e3254e99f82058d11a69e04 which seems unlikely to be related. I wonder if there is something wonky about your Perl installation. regards, tom lane
On Wed, Aug 24, 2011 at 11:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > bricklen <bricklen@gmail.com> writes: >> I was just testing a simple plperlu function to return the existence >> of a directory and as soon I pasted the function into psql and hit >> Enter, I got the following crash: > > FWIW, this function seems to work fine for me in 9.0.4 on a Fedora 14 > x86_64 box ... and there haven't been any bug fixes in plperl since > 9.0.2, except for this one > http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=cb252c2acd415d304e3254e99f82058d11a69e04 > which seems unlikely to be related. > > I wonder if there is something wonky about your Perl installation. I tested originally on two other 9.0.4 databases and there were no issues at all. I'll have to assume that you are correct about the Perl setup on that server -- I'm quite leery of doing anything else with that server as it is a production db. I'll consider this a lesson learned, and not test any other Perl functions on that db. Cheers
On Wed, Aug 24, 2011 at 12:32, bricklen <bricklen@gmail.com> wrote: > On Wed, Aug 24, 2011 at 11:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I wonder if there is something wonky about your Perl installation. > > I tested originally on two other 9.0.4 databases and there were no > issues at all. I'll have to assume that you are correct about the Perl > setup on that server -- I'm quite leery of doing anything else with > that server as it is a production db. Hrm, do simple plperlu functions break it? I can't tell from your report if plperlu seems completely broken or if something in your quoted function seems to be the culprit. If CREATE OR REPLACE FUNCTION plperlu_noop() returns void as $$ $$ language plperlu; select plperlu_noop(); works fine, I would wager someone upgraded perl and forgot to recompile (or upgrade?) postgres along with it. That or you have more than one perl installed and its somehow picking the wrong libperl...
On Wed, Aug 24, 2011 at 12:11 PM, Alex Hunsaker <badalex@gmail.com> wrote: > Hrm, do simple plperlu functions break it? I can't tell from your > report if plperlu seems completely broken or if something in your > quoted function seems to be the culprit. > > If > CREATE OR REPLACE FUNCTION plperlu_noop() returns void as $$ $$ > language plperlu; > select plperlu_noop(); > > works fine, I would wager someone upgraded perl and forgot to > recompile (or upgrade?) postgres along with it. That or you have more > than one perl installed and its somehow picking the wrong libperl... IIRC, plperl(u) was installed via yum at the same time the db was upgraded to 9.0.x. It is possible there is more than one Perl version installed, or that the original Perl installation was botched. I'm not willing to test even the simple example above, because it's a production database. The orignal (failing) plperlu function didn't even get as far as the execution phase, that segfault happened immediately after it compiled. Cheers
bricklen <bricklen@gmail.com> writes:
> On Wed, Aug 24, 2011 at 12:11 PM, Alex Hunsaker <badalex@gmail.com> wrote:
>> Hrm, do simple plperlu functions break it?
> IIRC, plperl(u) was installed via yum at the same time the db was
> upgraded to 9.0.x. It is possible there is more than one Perl version
> installed, or that the original Perl installation was botched.
> I'm not willing to test even the simple example above, because it's a
> production database. The orignal (failing) plperlu function didn't
> even get as far as the execution phase, that segfault happened
> immediately after it compiled.
I agree you probably don't want to poke at this in your production
instance, but you could create a playpen instance (separate data
directory, nondefault port number) using the same executables and
then do your testing there. If you didn't want to get plperl going
on that machine, why'd you try it in the first place?
regards, tom lane
On Wed, Aug 24, 2011 at 1:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I agree you probably don't want to poke at this in your production > instance, but you could create a playpen instance (separate data > directory, nondefault port number) using the same executables and > then do your testing there. If you didn't want to get plperl going > on that machine, why'd you try it in the first place? Good idea about using a separate data dir etc, I'll try that out. As far as not wanting plperl in the first place, I didn't mean to imply that. I've used plperl(u) functions before (but not since 8.4), so it was never an issue on this particular production machine before. I've had no problems in the other dev and test databases where I've found uses for plperl functions -- none are currently lower than 9.0.4 however.