On Sun, May 17, 2009 at 1:01 AM, Tom Lane wrote:
> Dave Page 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=0x,
>> _PerlIO * * f=0x, int fd=0, int imo
Dave Page 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=0x,
> _PerlIO * * f=0x, int fd=0, int imode=0) Line 2548 + 0xc
> bytes C
> perl510.dll!Perl
On Sat, May 16, 2009 at 7:37 PM, Dave Page 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()
On Sat, May 16, 2009 at 7:28 PM, Tom Lane wrote:
> Dave Page 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()
Dave Page 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_
On Fri, May 15, 2009 at 10:55 PM, Tom Lane 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. Then you don't hit it in any of the other processes.
Ooh, sneaky. I like it. Not sure it
Dave Page 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
On Fri, May 15, 2009 at 5:26 PM, Tom Lane wrote:
> Dave Page 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.
I've been playing with this for the last
Dave Page 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()
>> p
On Fri, May 15, 2009 at 3:47 PM, Tom Lane wrote:
> Dave Page writes:
>> On Fri, May 15, 2009 at 3:23 PM, Tom Lane 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 equivale
Dave Page writes:
> On Fri, May 15, 2009 at 3:23 PM, Tom Lane 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
On Fri, May 15, 2009 at 3:23 PM, Tom Lane 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 ...
Dave Page 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/messag
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.n3he7uri070
14 matches
Mail list logo
