plperl fails with perl 5.28

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:

2018-05-17 20:01:44.556 UTC [22629] pg_regress ERROR:
2018-05-17 20:01:44.556 UTC [22629] pg_regress CONTEXT: while running Perl initialization
2018-05-17 20:01:44.556 UTC [22629] pg_regress STATEMENT: CREATE EXTENSION IF NOT EXISTS "plperl"

Unfortunately this is all what I could extract from the server log,
even log_min_messages = debug5 doesn't print more.

Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899209

This is repeatable on Ubuntu.

I have a tiny bit more info:

andrew=# load 'plperl.so';
ERROR:
CONTEXT:  while running Perl initialization
andrew=#

That means it's failing at line 860 of plperl.c.

Maybe we need to fire up the perl debugger ...

cheers

andrew

--

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

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?)

regards, tom lane

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

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

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?

Yeah, it seems that mainly what they're doing is trying to resolve
the confusion about that.

regards, tom lane

Re: Tom Lane 2018-05-23 <23260.1527026547@sss.pgh.pa.us>

but TBH I think someone oughta file a bug report first.

https://rt.perl.org/Public/Bug/Display.html?id=133220

Christoph

Christoph Berg <myon@debian.org> writes:

Re: Tom Lane 2018-05-23 <23260.1527026547@sss.pgh.pa.us>

but TBH I think someone oughta file a bug report first.

https://rt.perl.org/Public/Bug/Display.html?id=133220

Thanks. Looking at this again, it seems like the core of the problem
is that S_run_body's fell-off-the-end behavior is equivalent to an
explicit "exit(0)". Perhaps it should not be. I can see the point of
treating "exit(0)" as an unusual quasi-error case, but fell-off-the-end
probably shouldn't be.

However, then somebody would have to look around and see if there are
any other uses of my_exit(0) that need to be rethought ...

regards, tom lane

Re: Tom Lane 2018-05-23 <10366.1527109807@sss.pgh.pa.us>

https://rt.perl.org/Public/Bug/Display.html?id=133220

Thanks. Looking at this again, it seems like the core of the problem
is that S_run_body's fell-off-the-end behavior is equivalent to an
explicit "exit(0)". Perhaps it should not be. I can see the point of
treating "exit(0)" as an unusual quasi-error case, but fell-off-the-end
probably shouldn't be.

However, then somebody would have to look around and see if there are
any other uses of my_exit(0) that need to be rethought ...

The perl_run() part of the change was just reverted:
https://rt.perl.org/Ticket/Display.html?id=133220#txn-1556788

Christoph