Re: psql leaking? - SOLVED - Mailing list pgsql-general

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