Re: plperl fails with perl 5.28 - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: plperl fails with perl 5.28
Date
Msg-id 3c48cd1d-b4b8-d464-4431-ce4b33b4dc9a@2ndQuadrant.com
Whole thread Raw
In response to Re: plperl fails with perl 5.28  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plperl fails with perl 5.28  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 05/22/2018 06:02 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 05/22/2018 07:18 AM, Christoph Berg wrote:
>>> plperl fails to install with perl 5.27.11, which is to be released as 5.28.0:
>> I have a tiny bit more info:
>>      andrew=# load 'plperl.so';
>>      ERROR:
>>      CONTEXT:  while running Perl initialization
>>      andrew=#
> I get the same behavior with a build of 5.27.11 on Fedora 28.
>
>> That means it's failing at line 860 of plperl.c.
> Tracing through it, the problem is that perl_run is returning 0x100,
> rather than zero as we expect, even though there was no failure.
> This happens because perl.c:S_run_body() falls off the end of the
> initialization code and does "my_exit(0);".  Apparently it's done that for
> a long time, but what's new is that perl_run() does this in response
> after catching the longjmp from my_exit():
>
>          if (exit_called) {
>              ret = STATUS_EXIT;
>              if (ret == 0) ret = 0x100;
>          } else {
>              ret = 0;
>          }
>
> That traces to this recent commit:
>
> https://perl5.git.perl.org/perl.git/commitdiff/0301e899536a22752f40481d8a1d141b7a7dda82
>
> which seems rather brain-dead from here, because it claims that it's
> defining perl_run's result as a truth value, which it is not any more.
>
> So assuming that this holds and the Perl guys don't see the error
> of their ways, we'd need something like this, I think:
>
> -        if (perl_run(plperl) != 0)
> +        if ((perl_run(plperl) & 0xFF) != 0)
>
> but TBH I think someone oughta file a bug report first.  They can't
> seriously intend that callers must do that, especially when there does
> not seem to be any big bold warning about it in perl*delta.pod.
>
> (Also, since perl_parse and perl_run are now specified to have identical
> return conventions, we'd probably want to change the perl_parse call
> likewise, even though it's not failing today.)
>
> (Alternatively, perhaps it's a bad idea that the plperl initialization
> script falls off the end rather than explicitly returning?)
>
>     


Well diagnosed. Maybe it's worth pointing out that almost all the 
examples of perl_run() in the perlembed manual simply ignore the 
returned value. OTOH, if that's what we're supposed to do why isn't the 
function declared that way?

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] (Windows) psql echoes password when reading from pipe
Next
From: Tom Lane
Date:
Subject: Re: plperl fails with perl 5.28