Обсуждение: plperl fails with perl 5.28
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
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