Re: BUG #1736: endless loop in PQconnectdb

From: Karsten Desler <kdesler(at)soohrt(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1736: endless loop in PQconnectdb
Date: 2005-07-03 16:49:20
Message-ID: 20050703164920.GA1892@soohrt.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

* Tom Lane wrote:
> Karsten Desler <kdesler(at)soohrt(dot)org> writes:
> > * Bruce Momjian wrote:
> >> I think what you are seeing is that the getaddrinfo memory is placed in
> >> the PGconn structure that isn't freed until PQclear is called. Does
> >> your test call PQclear()?
>
> > s/PQclear/PQfinish/
> > It does call PQclear on the result, and PQfinish on the connection.
>
> In that case I think there is no doubt that you've found a bug in
> getaddrinfo/freeaddrinfo, and you ought to be reporting it to your
> libc provider. We do call freeaddrinfo on the result of getaddrinfo,
> so if not everything is cleaned up, that's a library bug not ours.
>
> You could check this by reducing the test case to getaddrinfo()
> then freeaddrinfo() using the same parameters that fe-connect.c
> passes.

Indeed. Sorry for the noise.
The GNU libc 2.3.2 leaks ai->ai_canonname for every struct addrinfo
in the result list.

The original problem hasn't happened again (it seems like the faulty
ethernet switch, that was the cause for the flaky connection was
finally replaced). Anyway, if it happenes again, I'll notify you.

Regards,
Karsten Desler

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jean-Max Reymond 2005-07-03 20:40:05 Re: BUG #1739: memory leak in pl/perl with spi_exec_query
Previous Message Alvaro Herrera 2005-07-03 16:09:05 Re: BUG #1748: Unique contraints cannot be added to long text fields