Re: [HACKERS] pl/perl extension fails on Windows - Mailing list pgsql-hackers

From Ashutosh Sharma
Subject Re: [HACKERS] pl/perl extension fails on Windows
Date
Msg-id CAE9k0PkWhEeNS4b5bnoQLeZsnqe4zqkr=4GhN2Ybt1nSsBFk2g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pl/perl extension fails on Windows  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] pl/perl extension fails on Windows
List pgsql-hackers
On Thu, Jul 13, 2017 at 12:01 AM, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:
> On 07/12/2017 11:49 AM, Dave Page wrote:
>>
>>
>> Well crake is a Fedora box - and we have no problems on Linux, only on
>> Windows.
>>
>>
>
>
> Yeah, I have this on one of my Windows boxes, and haven't had time to
> get to the bottom of it yet ;-(
>

I could also see this problem in my Windows machine and I have spent
some time to analyse it.  Here are my findings:

The stacktrace where the crash happens is:
 perl524.dll!Perl_xs_handshake(const unsigned long key, void
*v_my_perl, const char * file, ...)  Line 5569 C plperl.dll!boot_PostgreSQL__InServer__Util(interpreter * my_perl, cv
* cv)  Line 490 + 0x22 bytes C perl524.dll!Perl_pp_entersub(interpreter * my_perl)  Line 3987 + 0xc bytes C
perl524.dll!Perl_runops_standard(interpreter* my_perl)  Line 41 + 0x6 bytes C perl524.dll!S_run_body(interpreter *
my_perl,long oldscope)  Line 2485 C perl524.dll!perl_run(interpreter * my_perl)  Line 2406 + 0xc bytes C
plperl.dll!plperl_init_interp() Line 829 + 0xb bytes C plperl.dll!_PG_init()  Line 470 + 0x5 bytes C
 

I couldn't get much out of above bt, but, one thing i could notice is
that the input key passed to 'Perl_xs_handshake()' function is not
matching with the key being generated inside 'Perl_xs_handshake()',
hence, the handshaking is failing.

Please have a look into the following code snippet from 'perl 5.24'
and 'Util.c' file in plperl respectively,

Perl-5.24:
=======   got = INT2PTR(void*, (UV)(key & HSm_KEY_MATCH));   need = (void *)(HS_KEY(FALSE, FALSE, "", "") &
HSm_KEY_MATCH);  if (UNLIKELY(got != need))       goto bad_handshake;
 

Util.c in plperl:
==========
485 XS_EXTERNAL(boot_PostgreSQL__InServer__Util)
486 {
487 #if PERL_VERSION_LE(5, 21, 5)
488    dVAR; dXSARGS;
489 #else
490    dVAR; dXSBOOTARGSAPIVERCHK;

Actually the macro 'dXSBOOTARGSAPIVERCHK' in line #490 gets expanded to,

#define XS_APIVERSION_SETXSUBFN_POPMARK_BOOTCHECK        \   Perl_xs_handshake(HS_KEY(TRUE, TRUE, "v"
PERL_API_VERSION_STRING,
""),      \       HS_CXT, __FILE__, "v" PERL_API_VERSION_STRING)

And the point to be noted is, the way, the key is being generated in
above macro and in Perl_xs_handshake(). As shown above,
'XS_APIVERSION_SETXSUBFN_POPMARK_BOOTCHECK' macro passes
'PERL_API_VERSION_STRING' as input to HS_KEY() to generate the key and
this key is passed to Perl_xs_handshake function whereas inside
Perl_xs_handshake(), there is no such version string being used to
generate the key. Hence, the key mismatch is seen thereby resulting in
a bad_handshake error.

After doing some study, I could understand that Util.c is generated
from Util.xs by xsubpp compiler at build time. This is being done in
Mkvcbuild.pm file in postgres. If I manually replace
'dXSBOOTARGSAPIVERCHK' macro with 'dXSBOOTARGSNOVERCHK' macro in
src/pl/plperl/Util.c, the things work fine. The diff is as follows,

XS_EXTERNAL(boot_PostgreSQL__InServer__Util)
{
#if PERL_VERSION_LE(5, 21, 5)   dVAR; dXSARGS;
#else
-    dVAR; dXSBOOTARGSAPIVERCHK;
+    dVAR; dXSBOOTARGSNOVERCHK;

I need to further investigate, but let me know if you have any ideas.

>
> Latest versions of ActivePerl don't ship with library descriptor files,
> either, which is unpleasant.
>

I too had similar observation and surprisingly, I am seeing
'libperl*.a' file instead of 'perl*.lib' file in most of  the
ActiverPerl versions for Windows.

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server
Next
From: Etsuro Fujita
Date:
Subject: Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables