Thread: readline usage in psql...

A dump from using psql....  this is one of those helpful, "I have no
clue what's causing this, but here it is for the record or someone who
knows more than I."  I don't know if it's a readline() problem or
something in PQclientEncoding(), and neither of which I have any
experience with.  If I figure out what's causing it beyond pushing
"Ctrl+something" with a halfway completed connect command (\c
datab[ctrl+???]), I'll post a reply w/ more info.  -sc

#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

--
Sean Chittenden

Sean Chittenden <sean@chittenden.org> writes:
> #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?

            regards, tom lane

> > #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

Sean Chittenden <sean@chittenden.org> writes:
> 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.

You sure you didn't send it a SIGQUIT with that ctrl-key combination?
This may just be the terminal driver doing what it's supposed to ...

            regards, tom lane