> Hmm, crash inside getenv?? That's weird, that suggests something has
> clobbered the environment-strings data structure.
>
> [ pokes around in code... ] And behold, here's a smoking gun:
> pg_GSS_recvauth() is doing a putenv() with a string that it got from
> palloc(). The active context at th
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0056bfde in getenv () from /lib/libc.so.6
> (gdb) bt
> #0 0x0056bfde in getenv () from /lib/libc.so.6
> #1 0x005c1490 in tzset_internal () from /lib/libc.so.6
> #2 0x005c1fad in tzset () from /l
> > No, we want a stack trace from the crash. You could attach gdb to the
> > child process after forking and before you provoke the crash; or arrange
> > for a core dump file to be produced and gdb that.
>
> I should be able to get that for you tomorrow, if we don't figure out
> the issue sooner.
> I think you misunderstand what is happening. The parent postmaster
> process is not restarting, because it did not crash. The crash is
> happening in a child process that is forked off by the postmaster to
> service a particular connection.
I see what you're saying, that it's one particular co
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> Trying to connect via GSSAPI (with Kerberos 5 as the underlying mechanism)
> after the server has been under a very slight load results in an unusable
> but still running server.
I couldn't reproduce this at all on Fedora 8. I speculate that you've
not
On Jan 25, 2008 4:31 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Can you get us a stack trace from that crash?
Here's the trace of the server process post-crash.
[EMAIL PROTECTED] ~]# gdb -p 24078
(gdb) bt
#0 0x006ac402 in __kernel_vsyscall ()
#1 0x0060801d in ___newselect_nocancel () from /lib/l
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> Looking into it more, it looks like the server is restarting every
> time it encounters this. I was wrong thinking that it stayed crashed,
> I guess I was just looking at a stale connection.
I think you misunderstand what is happening. The parent postm
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> Trying to connect via GSSAPI (with Kerberos 5 as the underlying mechanism)
> after the server has been under a very slight load results in an unusable
> but still running server.
Can you get us a stack trace from that crash?
reg
The following bug has been logged online:
Bug reference: 3902
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3RC2
Operating system: Red Hat Enterprise Linux 5
Description:Segmentation faults using GSSAPI authentication
Details:
Trying
