> > #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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
