Thread: Perl 5.10 vs. PG 8.4 on Win32

Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
CREATE LANGUAGE plperl; causes a backend crash on 8.4 with ActivePerl
5.10.0 (running on XP Pro). I'm testing this on beta 2 which I just
rolled, however I believe this is probably the same issue that Kevin
Field was reporting here:
http://archives.postgresql.org/message-id/200904171407.n3HE7uri070869@wwwmaster.postgresql.org.
For info, 0xC0000005 is a pretty general access violation error.

I couldn't get much out of the server in the way of logs:

2009-05-15 11:40:29 BST DEBUG:  StartTransactionCommand
2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
2009-05-15 11:40:29 BST DEBUG:  StartTransaction
2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
2009-05-15 11:40:29 BST DEBUG:  name: unnamed; blockState:
DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
2009-05-15 11:40:29 BST LOG:  statement: create language plperl;
2009-05-15 11:40:29 BST DEBUG:  ProcessUtility
2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
2009-05-15 11:40:29 BST DEBUG:  shmem_exit(-1)
2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
2009-05-15 11:40:29 BST DEBUG:  proc_exit(-1)
2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
2009-05-15 11:40:29 BST DEBUG:  reaping dead processes
2009-05-15 11:40:29 BST DEBUG:  server process (PID 3432) was
terminated by exception 0xC0000005
2009-05-15 11:40:29 BST HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.
2009-05-15 11:40:29 BST LOG:  server process (PID 3432) was terminated
by exception 0xC0000005
2009-05-15 11:40:29 BST HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.
2009-05-15 11:40:29 BST LOG:  terminating any other active server processes
2009-05-15 11:40:29 BST DEBUG:  sending SIGQUIT to process 3016
2009-05-15 11:40:29 BST DEBUG:  sending SIGQUIT to process 2336
2009-05-15 11:40:29 BST DEBUG:  sending SIGQUIT to process 2920
2009-05-15 11:40:29 BST DEBUG:  shmem_exit(-1)
2009-05-15 11:40:29 BST DEBUG:  proc_exit(-1)
2009-05-15 11:40:29 BST DEBUG:  sending SIGQUIT to process 3012
2009-05-15 11:40:29 BST DEBUG:  shmem_exit(-1)
2009-05-15 11:40:29 BST DEBUG:  proc_exit(-1)
2009-05-15 11:40:29 BST DEBUG:  shmem_exit(-1)
2009-05-15 11:40:29 BST DEBUG:  proc_exit(-1)
2009-05-15 11:40:29 BST DEBUG:  reaping dead processes
2009-05-15 11:40:29 BST DEBUG:  reaping dead processes
2009-05-15 11:40:29 BST LOG:  all server processes terminated; reinitializing
2009-05-15 11:40:29 BST DEBUG:  shmem_exit(1)
2009-05-15 11:40:29 BST DEBUG:  invoking IpcMemoryCreate(size=37052416)


--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Tom Lane
Date:
Dave Page <dpage@pgadmin.org> writes:
> CREATE LANGUAGE plperl; causes a backend crash on 8.4 with ActivePerl
> 5.10.0 (running on XP Pro). I'm testing this on beta 2 which I just
> rolled, however I believe this is probably the same issue that Kevin
> Field was reporting here:
> http://archives.postgresql.org/message-id/200904171407.n3HE7uri070869@wwwmaster.postgresql.org.
> For info, 0xC0000005 is a pretty general access violation error.

> I couldn't get much out of the server in the way of logs:

> 2009-05-15 11:40:29 BST DEBUG:  shmem_exit(-1)
> 2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
> 2009-05-15 11:40:29 BST DEBUG:  proc_exit(-1)
> 2009-05-15 11:40:29 BST STATEMENT:  create language plperl;
> 2009-05-15 11:40:29 BST DEBUG:  reaping dead processes
> 2009-05-15 11:40:29 BST DEBUG:  server process (PID 3432) was
> terminated by exception 0xC0000005

Ho, that's pretty curious.  The first two messages are the trace of the
atexit hook I recently installed, which means something called exit()
or the moral equivalent thereof.  I wouldn't really expect that to
happen in a crash situation ... is Windows dumb enough to try to run
the atexit hooks of a crashed process?

> 2009-05-15 11:40:29 BST DEBUG:  sending SIGQUIT to process 2920
> 2009-05-15 11:40:29 BST DEBUG:  shmem_exit(-1)
> 2009-05-15 11:40:29 BST DEBUG:  proc_exit(-1)

... and this proves I broke something :-( ... quickdie() is deliberately
not supposed to run through the proc_exit stuff.  Will fix.  That's not
related to your Perl problem though.

            regards, tom lane

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
On Fri, May 15, 2009 at 3:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Ho, that's pretty curious. =A0The first two messages are the trace of the
> atexit hook I recently installed, which means something called exit()
> or the moral equivalent thereof. =A0I wouldn't really expect that to
> happen in a crash situation ... is Windows dumb enough to try to run
> the atexit hooks of a crashed process?

Hmm, the MSDN docs don't say whether or not it will. A quick test,
forcing a crash by writing beyond the end of a char array shows that
it does follow spec and doesn't call the hooks.

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Tom Lane
Date:
Dave Page <dpage@pgadmin.org> writes:
> On Fri, May 15, 2009 at 3:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Ho, that's pretty curious.  The first two messages are the trace of the
>> atexit hook I recently installed, which means something called exit()
>> or the moral equivalent thereof.  I wouldn't really expect that to
>> happen in a crash situation ... is Windows dumb enough to try to run
>> the atexit hooks of a crashed process?

> Hmm, the MSDN docs don't say whether or not it will. A quick test,
> forcing a crash by writing beyond the end of a char array shows that
> it does follow spec and doesn't call the hooks.

Try setting a breakpoint at atexit_callback() and seeing how it got
there in the CREATE LANGUAGE test case.

            regards, tom lane

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
On Fri, May 15, 2009 at 3:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> On Fri, May 15, 2009 at 3:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Ho, that's pretty curious. =A0The first two messages are the trace of t=
he
>>> atexit hook I recently installed, which means something called exit()
>>> or the moral equivalent thereof. =A0I wouldn't really expect that to
>>> happen in a crash situation ... is Windows dumb enough to try to run
>>> the atexit hooks of a crashed process?
>
>> Hmm, the MSDN docs don't say whether or not it will. A quick test,
>> forcing a crash by writing beyond the end of a char array shows that
>> it does follow spec and doesn't call the hooks.
>
> Try setting a breakpoint at atexit_callback() and seeing how it got
> there in the CREATE LANGUAGE test case.

Getting past the exception to get to the atexit_callback() breakpoint
in the debugger is proving a little tricky right now (and I have to
leave for the moment), so I'll play with that some more later.
Couldn't the callback have been called by another process though? The
crash did bring down the entire server, so assume other backends would
have terminated normally on the postmasters instruction.

Anyhoo, here's the backtrace for the actual problem:

...
     perl510.dll!28028026()=20=09
>    plperl.dll!plperl_init_interp()  Line 452    C
     plperl.dll!_PG_init()  Line 229    C
     postgres.exe!internal_load_library(const char * libname=3D0x01372048)
Line 287    C
     postgres.exe!load_external_function(char * filename=3D0x013710d8, char
* funcname=3D0x01372bf0, char signalNotFound=3D' ', void * *
filehandle=3D0x00caf678)  Line 116    C
     postgres.exe!fmgr_c_validator(FunctionCallInfoData *
fcinfo=3D0x00caf600)  Line 647    C
     postgres.exe!OidFunctionCall1(unsigned int functionId=3D2247, unsigned
long arg1=3D40962)  Line 1561 + 0x2f bytes    C
     postgres.exe!ProcedureCreate(const char * procedureName=3D0x01372120,
unsigned int procNamespace=3D11, char replace=3D0, char returnsSet=3D0,
unsigned int returnType=3D2280, unsigned int languageObjectId=3D13,
unsigned int languageValidator=3D2247, const char * prosrc=3D0x01372120,
const char * probin=3D0x01372a68, char isAgg=3D0, char isWindowFunc=3D0,
char security_definer=3D0, char isStrict=3D0, char volatility=3D'v',
oidvector * parameterTypes=3D0x01372ac8, unsigned long
allParameterTypes=3D0, unsigned long parameterModes=3D0, unsigned long
parameterNames=3D0, List * parameterDefaults=3D0x00000000, unsigned long
proconfig=3D0, float procost=3D1.0000000, float prorows=3D0.00000000)  Line
550 + 0x7 bytes    C
     postgres.exe!CreateProceduralLanguage(CreatePLangStmt *
stmt=3D0x0132c960)  Line 154 + 0x52 bytes    C
     postgres.exe!ProcessUtility(Node * parsetree=3D0x0132c960, const char
* queryString=3D0x0132c118, ParamListInfoData * params=3D0x00000000, char
isTopLevel=3D' ', _DestReceiver * dest=3D0x0132cb10, char *
completionTag=3D0x00cafbc0)  Line 961 + 0x6 bytes    C
     postgres.exe!PortalRunUtility(PortalData * portal=3D0x00000000, Node *
utilityStmt=3D0x00000000, char isTopLevel=3D' ', _DestReceiver *
dest=3D0x0132cb10, char * completionTag=3D0x00cafbc0)  Line 1200    C
     postgres.exe!PortalRunMulti(PortalData * portal=3D0x00000000, char
isTopLevel=3D' ', _DestReceiver * dest=3D0x0132cb10, _DestReceiver *
altdest=3D0x0132cb10, char * completionTag=3D0x00cafbc0)  Line 1299 + 0x11
bytes    C
     postgres.exe!PortalRun(PortalData * portal=3D0x01372fc0, long
count=3D2147483647, char isTopLevel=3D' ', _DestReceiver *
dest=3D0x0132cb10, _DestReceiver * altdest=3D0x0132cb10, char *
completionTag=3D0x00cafbc0)  Line 824 + 0x17 bytes    C
     postgres.exe!exec_simple_query(const char * query_string=3D0x00000000)
 Line 998    C
     postgres.exe!PostgresMain(int argc=3D4, char * * argv=3D0x012d5378,
const char * username=3D0x01115128)  Line 3610    C
     postgres.exe!BackendRun(Port * port=3D0x00cafd48)  Line 3390    C
     postgres.exe!SubPostmasterMain(int argc=3D3, char * * argv=3D0x01112950)
 Line 3862 + 0x8 bytes    C
     postgres.exe!main(int argc=3D3, char * * argv=3D0x01112950)  Line 165 +
0x7 bytes    C
     postgres.exe!__tmainCRTStartup()  Line 597 + 0x17 bytes    C





--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Tom Lane
Date:
Dave Page <dpage@pgadmin.org> writes:
> Couldn't the callback have been called by another process though?

Hmm, maybe, if the messages got to the log out of order.  Try
reproducing it with %p added to log_line_prefix.

> Anyhoo, here's the backtrace for the actual problem:

> ...
>      perl510.dll!28028026()
>> plperl.dll!plperl_init_interp()  Line 452    C
>      plperl.dll!_PG_init()  Line 229    C
>      postgres.exe!internal_load_library(const char * libname=0x01372048)
> Line 287    C

Seems it's crashing inside perl_run(), which leaves us little wiser than
before :-(

            regards, tom lane

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
On Fri, May 15, 2009 at 5:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> Couldn't the callback have been called by another process though?
>
> Hmm, maybe, if the messages got to the log out of order. =A0Try
> reproducing it with %p added to log_line_prefix.

I've been playing with this for the last couple of hours, to no avail.
Looking at the log with PIDs, it certainly appears to be the crashing
backend that calls the atexit callback. I can't get a backtrace though
- if I attach the debugger before crashing, it breaks out at the
exception and won't continue. If I add an infinite loop in
atexit_callback to 'pause' the process I can attach and break, but for
some reason the debugger doesn't recognise the loop control variable,
so I can't modify the value to make it continue. That stops me even
getting the server to complete startup :-(

> Seems it's crashing inside perl_run(), which leaves us little wiser than
> before :-(

Well, there's no symbols included with ActivePerl, I can't get any
more info from there. I don't know if there are any with perl.org's
builds - but I'm too tired to look now anyway.

Any other ideas would be welcome!!

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Tom Lane
Date:
Dave Page <dpage@pgadmin.org> writes:
> I've been playing with this for the last couple of hours, to no avail.
> Looking at the log with PIDs, it certainly appears to be the crashing
> backend that calls the atexit callback. I can't get a backtrace though
> - if I attach the debugger before crashing, it breaks out at the
> exception and won't continue. If I add an infinite loop in
> atexit_callback to 'pause' the process I can attach and break, but for
> some reason the debugger doesn't recognise the loop control variable,
> so I can't modify the value to make it continue. That stops me even
> getting the server to complete startup :-(

This is a bit devious, but ... add an on_proc_exit call that's set up
by plperl.c's init before it calls Perl, and put the infinite loop
inside there.  Then you don't hit it in any of the other processes.

            regards, tom lane

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
On Fri, May 15, 2009 at 10:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This is a bit devious, but ... add an on_proc_exit call that's set up
> by plperl.c's init before it calls Perl, and put the infinite loop
> inside there. =A0Then you don't hit it in any of the other processes.

Ooh, sneaky. I like it. Not sure it helps much though:

>    postgres.exe!atexit_callback()  Line 228    C
     msvcr80.dll!doexit(int code=3D0, int quick=3D0, int retcaller=3D1)  Line =
553    C
     msvcr80.dll!_cexit()  Line 413 + 0xb bytes    C
     msvcr80.dll!__CRTDLL_INIT(void * hDllHandle=3D0x78130000, unsigned
long dwReason=3D0, void * lpreserved=3D0x00000001)  Line 389    C
     msvcr80.dll!_CRTDLL_INIT(void * hDllHandle=3D0x78130000, unsigned long
dwReason=3D0, void * lpreserved=3D0x00000001)  Line 214 + 0x11 bytes    C
     ntdll.dll!7c90118a()=20=09
     [Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
     ntdll.dll!7c923ada()=20=09
     ntdll.dll!7c910435()=20=09
     ntdll.dll!7c91043e()=20=09
     ntdll.dll!7c923c88()=20=09
     kernel32.dll!7c81caae()=20=09
     postgres.exe!main(int argc=3D3, char * * argv=3D0x00262fc0)  Line 165 +
0x7 bytes    C
     postgres.exe!__tmainCRTStartup()  Line 597 + 0x17 bytes    C


--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Tom Lane
Date:
Dave Page <dpage@pgadmin.org> writes:
> Ooh, sneaky. I like it. Not sure it helps much though:

> postgres.exe!atexit_callback()  Line 228    C
>      msvcr80.dll!doexit(int code=0, int quick=0, int retcaller=1)  Line 553    C
>      msvcr80.dll!_cexit()  Line 413 + 0xb bytes    C
>      msvcr80.dll!__CRTDLL_INIT(void * hDllHandle=0x78130000, unsigned
> long dwReason=0, void * lpreserved=0x00000001)  Line 389    C
>      msvcr80.dll!_CRTDLL_INIT(void * hDllHandle=0x78130000, unsigned long
> dwReason=0, void * lpreserved=0x00000001)  Line 214 + 0x11 bytes    C
>      ntdll.dll!7c90118a()
>      [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
>      ntdll.dll!7c923ada()
>      ntdll.dll!7c910435()
>      ntdll.dll!7c91043e()
>      ntdll.dll!7c923c88()
>      kernel32.dll!7c81caae()
>      postgres.exe!main(int argc=3, char * * argv=0x00262fc0)  Line 165 +
> 0x7 bytes    C
>      postgres.exe!__tmainCRTStartup()  Line 597 + 0x17 bytes    C

I think you must've traced the wrong process --- this looks like an exit
from main().  There should be a pile of stack frames for Postgres
functions if we are inside a call from plperl.c to the Perl dll.

            regards, tom lane

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
On Sat, May 16, 2009 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> Ooh, sneaky. I like it. Not sure it helps much though:
>
>> postgres.exe!atexit_callback() =A0Line 228 =A0 =A0 =A0C
>> =A0 =A0 =A0 msvcr80.dll!doexit(int code=3D0, int quick=3D0, int retcalle=
r=3D1) =A0Line 553 =A0C
>> =A0 =A0 =A0 msvcr80.dll!_cexit() =A0Line 413 + 0xb bytes =A0 =A0 =A0C
>> =A0 =A0 =A0 msvcr80.dll!__CRTDLL_INIT(void * hDllHandle=3D0x78130000, un=
signed
>> long dwReason=3D0, void * lpreserved=3D0x00000001) =A0Line 389 =A0 =A0 =
=A0C
>> =A0 =A0 =A0 msvcr80.dll!_CRTDLL_INIT(void * hDllHandle=3D0x78130000, uns=
igned long
>> dwReason=3D0, void * lpreserved=3D0x00000001) =A0Line 214 + 0x11 bytes =
=A0 =A0 =A0C
>> =A0 =A0 =A0 ntdll.dll!7c90118a()
>> =A0 =A0 =A0 [Frames below may be incorrect and/or missing, no symbols lo=
aded for
>> ntdll.dll]
>> =A0 =A0 =A0 ntdll.dll!7c923ada()
>> =A0 =A0 =A0 ntdll.dll!7c910435()
>> =A0 =A0 =A0 ntdll.dll!7c91043e()
>> =A0 =A0 =A0 ntdll.dll!7c923c88()
>> =A0 =A0 =A0 kernel32.dll!7c81caae()
>> =A0 =A0 =A0 postgres.exe!main(int argc=3D3, char * * argv=3D0x00262fc0) =
=A0Line 165 +
>> 0x7 bytes =A0 =A0 C
>> =A0 =A0 =A0 postgres.exe!__tmainCRTStartup() =A0Line 597 + 0x17 bytes C
>
> I think you must've traced the wrong process --- this looks like an exit
> from main(). =A0There should be a pile of stack frames for Postgres
> functions if we are inside a call from plperl.c to the Perl dll.

Well, I added a dummy callback to plperl.c, and added the hook it in
the plperl.c init function. The dummy callback simply slept for 60
seconds to let me attach the debugger. I attached and broke to confirm
I was where I expected. I then stepped out of my dummy callback (which
was below DLLMain in it's backtrace btw) and let it run to a
breakpoint in the real atexit_callback, which is where this backtrace
is from. As far as I can tell, it is from the right process, as only
the correct one should have added the foo_callback hook.

BTW, I'm currently attempting to build perl myself so I can get a more
helpful backtrace. Strawberry perl exhibits the same crash and doesn't
come with symbols either.

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
On Sat, May 16, 2009 at 7:37 PM, Dave Page <dpage@pgadmin.org> wrote:

> BTW, I'm currently attempting to build perl myself so I can get a more
> helpful backtrace. Strawberry perl exhibits the same crash and doesn't
> come with symbols either.

Hmm, that was easier than I expected:

     ntdll.dll!7c91b21a()=20=09
     [Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
     msvcrt.dll!77c2c3c9()=20=09
     msvcrt.dll!77c2c3ce()=20=09
     msvcrt.dll!77c2c3ce()=20=09
     msvcrt.dll!77c2c3e7()=20=09
     msvcrt.dll!77c2c42e()=20=09
     perl510.dll!VMem::FreeLock()  Line 245    C++
     ntdll.dll!7c901046()=20=09
     perl510.dll!PerlIOUnix_refcnt_inc(int fd=3D0)  Line 2339    C
     perl510.dll!PerlIOUnix_setfd(interpreter * my_perl=3D0x00000000,
_PerlIO * * f=3D0x00000000, int fd=3D0, int imode=3D0)  Line 2548 + 0xc
bytes    C
     perl510.dll!PerlIOUnix_open(interpreter * my_perl=3D0x00242544,
_PerlIO_funcs * self=3D0x280cb548, PerlIO_list_s * layers=3D0x012d3494,
long n=3D0, const char * mode=3D0x280be040, int fd=3D0, int imode=3D0, int
perm=3D0, _PerlIO * * f=3D0x00000000, int narg=3D0, sv * * args=3D0x0000000=
0)
Line 2626    C
     perl510.dll!PerlIOBuf_open(interpreter * my_perl=3D0x00242544,
_PerlIO_funcs * self=3D0x280cb708, PerlIO_list_s * layers=3D0x012d3494,
long n=3D1, const char * mode=3D0x280be040, int fd=3D0, int imode=3D0, int
perm=3D0, _PerlIO * * f=3D0x00000000, int narg=3D0, sv * * args=3D0x0000000=
0)
Line 3685 + 0x1b bytes    C
     perl510.dll!PerlIO_openn(interpreter * my_perl=3D0x00242544, const
char * layers=3D0x00000000, const char * mode=3D0x280be040, int fd=3D0, int
imode=3D0, int perm=3D0, _PerlIO * * f=3D0x00000000, int narg=3D0, sv * *
args=3D0x00000000)  Line 1597 + 0x1d bytes    C
     perl510.dll!PerlIO_fdopen(int fd=3D0, const char * mode=3D0x280be040)
Line 4988 + 0x16 bytes    C
     perl510.dll!PerlIO_stdstreams(interpreter * my_perl=3D0x00242544)  Line 1=
205    C
     perl510.dll!PerlIO_resolve_layers(interpreter * my_perl=3D0x012d3494,
const char * layers=3D0x00000000, const char * mode=3D0x280b36f0, int
narg=3D1, sv * * args=3D0x00caf11c)  Line 1486 + 0x6 bytes    C
     perl510.dll!PerlIO_openn(interpreter * my_perl=3D0x00242544, const
char * layers=3D0x00000000, const char * mode=3D0x280b36f0, int fd=3D-1, int
imode=3D0, int perm=3D0, _PerlIO * * f=3D0x00000000, int narg=3D1, sv * *
args=3D0x00caf11c)  Line 1568 + 0x14 bytes    C
     perl510.dll!PerlIO_open(const char * path=3D0x280b3a5c, const char *
mode=3D0x280b36f0)  Line 4997 + 0x15 bytes    C
     perl510.dll!S_open_script(interpreter * my_perl=3D0x00000000, const
char * scriptname=3D0x280b3a5c, char dosearch=3D0, sv * sv=3D0x002490f4, int
* suidscript=3D0x00000000, _PerlIO * * * rsfpp=3D0x00caf174)  Line 3704 +
0xb bytes    C
>    perl510.dll!S_parse_body(interpreter * my_perl=3D0x00242544, char * * env=
=3D0x00000000, void (interpreter *)* xsinit=3D0x10003420)  Line 2056    C
     perl510.dll!perl_parse(interpreter * my_perl=3D0x00242544, void
(interpreter *)* xsinit=3D0x10003420, int argc=3D3, char * *
argv=3D0x1000f000, char * * env=3D0x00000000)  Line 1651    C
     plperl.dll!plperl_init_interp()  Line 451    C
     plperl.dll!_PG_init()  Line 229    C
     postgres.exe!internal_load_library(const char * libname=3D0x012b7478)
Line 287    C
     postgres.exe!load_external_function(char * filename=3D0x012b7380, char
* funcname=3D0x012b7348, char signalNotFound=3D'=01', void * *
filehandle=3D0x00caf724)  Line 116    C
     postgres.exe!fmgr_c_validator(FunctionCallInfoData *
fcinfo=3D0x00caf700)  Line 647    C
     postgres.exe!OidFunctionCall1(unsigned int functionId=3D2247, unsigned
long arg1=3D49152)  Line 1561 + 0x2f bytes    C
     postgres.exe!ProcedureCreate(const char * procedureName=3D0x012ac3f0,
unsigned int procNamespace=3D11, char replace=3D0, char returnsSet=3D0,
unsigned int returnType=3D2280, unsigned int languageObjectId=3D13,
unsigned int languageValidator=3D2247, const char * prosrc=3D0x012ac3f0,
const char * probin=3D0x012ac680, char isAgg=3D0, char isWindowFunc=3D0,
char security_definer=3D0, char isStrict=3D0, char volatility=3D'v',
oidvector * parameterTypes=3D0x012b6ad8, unsigned long
allParameterTypes=3D0, unsigned long parameterModes=3D0, unsigned long
parameterNames=3D0, List * parameterDefaults=3D0x00000000, unsigned long
proconfig=3D0, float procost=3D1.0000000, float prorows=3D0.00000000)  Line
550 + 0x7 bytes    C
     postgres.exe!CreateProceduralLanguage(CreatePLangStmt *
stmt=3D0x0123d178)  Line 154 + 0x52 bytes    C
     postgres.exe!ProcessUtility(Node * parsetree=3D0x0123d178, const char
* queryString=3D0x0123c930, ParamListInfoData * params=3D0x00000000, char
isTopLevel=3D'=01', _DestReceiver * dest=3D0x0123d328, char *
completionTag=3D0x00cafc6c)  Line 961 + 0x6 bytes    C
     postgres.exe!PortalRunUtility(PortalData * portal=3D0x00000000, Node *
utilityStmt=3D0x00000000, char isTopLevel=3D'=01', _DestReceiver *
dest=3D0x0123d328, char * completionTag=3D0x00cafc6c)  Line 1200    C
     postgres.exe!PortalRunMulti(PortalData * portal=3D0x00000000, char
isTopLevel=3D'=01', _DestReceiver * dest=3D0x0123d328, _DestReceiver *
altdest=3D0x0123d328, char * completionTag=3D0x00cafc6c)  Line 1299 + 0x11
bytes    C
     postgres.exe!PortalRun(PortalData * portal=3D0x012b2300, long
count=3D2147483647, char isTopLevel=3D'=01', _DestReceiver *
dest=3D0x0123d328, _DestReceiver * altdest=3D0x0123d328, char *
completionTag=3D0x00cafc6c)  Line 824 + 0x17 bytes    C
     postgres.exe!exec_simple_query(const char * query_string=3D0x00000000)
 Line 998    C
     postgres.exe!PostgresMain(int argc=3D4, char * * argv=3D0x011d2f78,
const char * username=3D0x002660f8)  Line 3610    C
     postgres.exe!BackendRun(Port * port=3D0x00cafdf8)  Line 3390    C
     postgres.exe!SubPostmasterMain(int argc=3D3, char * * argv=3D0x00262fc0)
 Line 3862 + 0x8 bytes    C
     postgres.exe!main(int argc=3D3, char * * argv=3D0x00262fc0)  Line 165 +
0x7 bytes    C
     postgres.exe!__tmainCRTStartup()  Line 597 + 0x17 bytes    C
     kernel32.dll!7c817077()=20=09


--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Tom Lane
Date:
Dave Page <dpage@pgadmin.org> writes:
> Hmm, that was easier than I expected:

>      perl510.dll!PerlIOUnix_refcnt_inc(int fd=0)  Line 2339    C
>      perl510.dll!PerlIOUnix_setfd(interpreter * my_perl=0x00000000,
> _PerlIO * * f=0x00000000, int fd=0, int imode=0)  Line 2548 + 0xc
> bytes    C
>      perl510.dll!PerlIOUnix_open(interpreter * my_perl=0x00242544,
> _PerlIO_funcs * self=0x280cb548, PerlIO_list_s * layers=0x012d3494,
> long n=0, const char * mode=0x280be040, int fd=0, int imode=0, int
> perm=0, _PerlIO * * f=0x00000000, int narg=0, sv * * args=0x00000000)
> Line 2626    C

Hmmm ... you sure functions named like that should be getting called
in a Windows build?

            regards, tom lane

Re: Perl 5.10 vs. PG 8.4 on Win32

From
Dave Page
Date:
On Sun, May 17, 2009 at 1:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> Hmm, that was easier than I expected:
>
>> =A0 =A0 =A0 perl510.dll!PerlIOUnix_refcnt_inc(int fd=3D0) =A0Line 2339 =
=A0C
>> =A0 =A0 =A0 perl510.dll!PerlIOUnix_setfd(interpreter * my_perl=3D0x00000=
000,
>> _PerlIO * * f=3D0x00000000, int fd=3D0, int imode=3D0) =A0Line 2548 + 0xc
>> bytes C
>> =A0 =A0 =A0 perl510.dll!PerlIOUnix_open(interpreter * my_perl=3D0x002425=
44,
>> _PerlIO_funcs * self=3D0x280cb548, PerlIO_list_s * layers=3D0x012d3494,
>> long n=3D0, const char * mode=3D0x280be040, int fd=3D0, int imode=3D0, i=
nt
>> perm=3D0, _PerlIO * * f=3D0x00000000, int narg=3D0, sv * * args=3D0x0000=
0000)
>> Line 2626 =A0 =A0 C
>
> Hmmm ... you sure functions named like that should be getting called
> in a Windows build?

Well there are #ifdef WIN32 blocks in some of those PerlIOUnix
functions, so I assume they are expected to be used on Windows.

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com