> > #0 0x281cbaeb in sigprocmask () from /usr/lib/libc.so.5
> > #1 0x280c5a2a in _rl_savestring () from /usr/lib/libreadline.so.4
> > #2 <signal handler called>
> > #3 0x28168803 in read () from /usr/lib/libc.so.5
> > #4 0x280c1c79 in rl_read_key () from /usr/lib/libreadline.so.4
> > #5 0x280d407f in readline_internal_char () from /usr/lib/libreadline.so.4
> > #6 0x280d4235 in readline_internal_char () from /usr/lib/libreadline.so.4
> > #7 0x280d426e in readline_internal_char () from /usr/lib/libreadline.so.4
> > #8 0x280d3dad in readline () from /usr/lib/libreadline.so.4
> > #9 0x0804ede4 in PQclientEncoding () at fe-connect.c:2725
> > #10 0x0804f697 in PQclientEncoding () at fe-connect.c:2725
> > #11 0x08051653 in PQclientEncoding () at fe-connect.c:2725
> > #12 0x0804a485 in PQclientEncoding () at fe-connect.c:2725
>
> I don't believe a word of this backtrace; PQclientEncoding isn't
> recursive and it doesn't call readline.
>
> Possibly the stack is already corrupt by the time the coredump
> occurs?
Very very possible. I was sitting there at a psql prompt:
\c datab(ctrl+key I brushed against, but didn't intentionally push)
and next thing I knew I was back at a shell prompt, core dumped.
::scratches head::
After looking at the backtrace, I didn't know what to make of it other
than that it was unusual to say the least and I couldn't figure out a
good place to start poking at the code to possibly submit a patch, so
I punted. :-/ I'll see if I can't get more info if I run across this
again. -sc
GNU gdb 5.2.1 (FreeBSD)
--
Sean Chittenden
