Re: Perl 5.10 vs. PG 8.4 on Win32
От | Dave Page |
---|---|
Тема | Re: Perl 5.10 vs. PG 8.4 on Win32 |
Дата | |
Msg-id | 937d27e10905161137r6e235f5bk9a851b68ebecfae4@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Perl 5.10 vs. PG 8.4 on Win32 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Perl 5.10 vs. PG 8.4 on Win32
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: