Lists: | pgsql-hackers |
---|
From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | plperl fails with perl 5.28 |
Date: | 2018-05-22 11:18:46 |
Message-ID: | 20180522111846.GD1684@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
Christoph
From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl fails with perl 5.28 |
Date: | 2018-05-22 16:18:04 |
Message-ID: | 501e8b0d-25a8-d031-4c35-4895cb270214@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl fails with perl 5.28 |
Date: | 2018-05-22 22:02:27 |
Message-ID: | 23260.1527026547@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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
From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl fails with perl 5.28 |
Date: | 2018-05-22 22:56:36 |
Message-ID: | 3c48cd1d-b4b8-d464-4431-ce4b33b4dc9a@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 05/22/2018 06:02 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl fails with perl 5.28 |
Date: | 2018-05-22 23:00:29 |
Message-ID: | 26187.1527030029@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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
From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl fails with perl 5.28 |
Date: | 2018-05-23 20:47:55 |
Message-ID: | 20180523204754.GD17259@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Re: Tom Lane 2018-05-23 <23260(dot)1527026547(at)sss(dot)pgh(dot)pa(dot)us>
> but TBH I think someone oughta file a bug report first.
https://rt.perl.org/Public/Bug/Display.html?id=133220
Christoph
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl fails with perl 5.28 |
Date: | 2018-05-23 21:10:07 |
Message-ID: | 10366.1527109807@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Christoph Berg <myon(at)debian(dot)org> writes:
> Re: Tom Lane 2018-05-23 <23260(dot)1527026547(at)sss(dot)pgh(dot)pa(dot)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
From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl fails with perl 5.28 |
Date: | 2018-05-29 18:49:49 |
Message-ID: | 20180529184948.GA5510@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Re: Tom Lane 2018-05-23 <10366(dot)1527109807(at)sss(dot)pgh(dot)pa(dot)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