From: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | Dave Page <dpage(at)pgadmin(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pl/perl extension fails on Windows |
Date: | 2017-07-13 12:08:37 |
Message-ID: | CAE9k0PkWhEeNS4b5bnoQLeZsnqe4zqkr=4GhN2Ybt1nSsBFk2g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 13, 2017 at 12:01 AM, Andrew Dunstan
<andrew(dot)dunstan(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2017-07-13 12:10:20 | Re: Bug in ExecModifyTable function and trigger issues for foreign tables |
Previous Message | Michael Paquier | 2017-07-13 12:03:26 | Re: pg_stop_backup(wait_for_archive := true) on standby server |