Re: psql leaking?

Fixed it. On a whim I googled for '_HiStOrY_V2_', which I thought looked a
bit funny. It turned up source files for libedit, which from what I can
tell is supposed to be a readline replacement.

Sure enough, I had that library installed, so I uninstalled it and psql
refused to run at all, as I'd expected. So I recompiled postgresql and now
everything works. It seems that the postgesql build process picked up and
used libedit instead of readline: don't know if that's a core issue or a
gentoo ebuild issue...

Anyway, problem solved, and the moral of the story is libedit don't work
with psql. :-)

Thanks again Daniel.

On Sat, 04 Sep 2004 22:35:10 +0100, Russ Brown <postgres@dot4dot.plus.com>
wrote:

Thanks very much for your reply, Daniel.

I'm not a C programmer, so I don't really know anything about the tools
mentioned. I don't seem to get any core file at all when psql is
terminated (checked in the working directory, home directory and temp
directory): I reckon that's probably due to a system setting that
disables core dumps. I don't know what it might be though.

Anyway, I compiled strace and ltrace. ltrace gave no output, but strace
certainly did, and it helped me find a workaround to the problem (though
not a fix).

From what I can tell (and bearing in mind my lack of knowlege and
experience on this) strace shows that psql opens a number of files, most
of which are libraries. After this it goes into what looks like an
infinite loop with plenty of commands exactly like this:

read(4, "", 131072) = 0

Every now and then there are a pair of lines like this (but not exactly
the same values in each case):

brk(0) = 0x808e000
brk(0x80af000) = 0x80af000

So I looked at the last sane instructions before the loop, and its'
reading the history file:

open("/home/rbrown/.psql_history", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=384, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x403ad000
read(4, "_HiStOrY_V2_\nSET\\040search_path="..., 131072) = 384

So I moved the file away and it I was able to log into psql! Result! And
for the acid test, I quit and connected again. No go, same problem. So I
moved away the file again and it's fine.

So, the problem is the history file, and since I can move the file away
and have exactly the same problem happen again, I'm starting to wonder
if it's not a psql bug. But surely something like this would have
happened before? There must be something on my system that is prompting
the unusual behaviour from psql.

If anyone has any ideas I'll be happy to try them, but in the meantime I
have a workaround so I can get on with things.

Oh, and here's the content of the history file as written by just
opening and closing psql (obtained from cat):

_HiStOrY_V2_
\134l

Thanks again Daniel.

On Sat, 04 Sep 2004 23:03:32 +0200, Daniel Verite
<daniel@manitou-mail.org> wrote:

Russ Brown writes

I'm suspecting that there's a problem with one of the libraries that
psql uses: I really can't see this being a psql bug as I'd have

noticed

it before: there must be something else going on. Trouble is, I don't
know what libraries it uses other than glibc (which I'm currently
recompiling just in case).

libreadline, libtermcap?

I'm at a loss, and can't think of anything else. This has just

happened

totally unprompted and without any real clues that I can see.

Some suggestions:

- kill psql when it's errating and examine the stack of the resulting
core file
with gdb

- launch psql with strace and see if the output gives any clue.

- ditto with ltrace

Regards,

--

Russell Brown

"Russ Brown" <postgres@dot4dot.plus.com> writes:

It seems that the postgesql build process picked up and
used libedit instead of readline: don't know if that's a core issue or a
gentoo ebuild issue...

Hmm. Our configure code is *supposed* to be biased to choose readline
over libedit, but I think maybe the code needs a little work. It's
doing

for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
for pgac_rllib in -lreadline -ledit ; do
[ take the first working combination ]

ISTM it's possible for this to select libedit over readline when both
are available, if libedit chances to link with an earlier pgac_lib
alternative than readline does.

And that only affects the link choice. The choice of headers is made
separately and would go for the readline headers if available, no matter
what had happened in the link choice. It seems likely to me that your
failure has to do with compiling against readline headers and then
linking against libedit. Saying that libedit "don't work" with psql
is too simplistic, because it *do* work, at least for some people.

ISTM that we ought to

(1) modify PGAC_CHECK_READLINE so that it really does prefer readline
over libedit consistently. I think all this would take is switching
the loop order:

for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do

but possibly I'm missing something.

(2) fix the readline header selection so that it will only take the
headers that correspond to the selected library. These libraries are
more or less source-compatible but they do not have the same ABI, so
mix-and-match is not going to work.

Peter, any comments? Do you have time to fix this?

regards, tom lane

Tom Lane wrote:

(1) modify PGAC_CHECK_READLINE so that it really does prefer readline
over libedit consistently. I think all this would take is switching
the loop order:

for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do

but possibly I'm missing something.

That seems reasonable. I'm not really sure why the loops are nested the
other way.

(2) fix the readline header selection so that it will only take the
headers that correspond to the selected library. These libraries are
more or less source-compatible but they do not have the same ABI, so
mix-and-match is not going to work.

That sounds like a pretty hard problem to solve.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

(2) fix the readline header selection so that it will only take the
headers that correspond to the selected library.

That sounds like a pretty hard problem to solve.

It didn't seem that bad to me. One problem is to not select, eg,
<readline/readline.h> in preference to <editline/readline.h> if we've
selected libedit for linking to. (I think that is the behavior that
bit Russ.) But that seems a small matter of paying attention to a flag
variable set by PGAC_CHECK_READLINE. The other problem is that if we
select <readline.h> we can't really be sure it matches the selected
library. I'm not sure that we *need* to solve that --- if you have
readline.so and not <readline/readline.h> then <readline.h> had better
be the right thing. But I would think it could be done with some
appropriate AC_EGREP_HEADER check if you wanted to be paranoid.

regards, tom lane