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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Perl 5.10 vs. PG 8.4 on Win32
Следующее
От: Dave Page
Дата:
Сообщение: Re: Perl 5.10 vs. PG 8.4 on Win32