Thread: Perl 5.10 vs. PG 8.4 on Win32
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
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
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
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
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
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
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
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
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
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
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
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
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
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