BUG #15627: libpq memory leak

Lists: pgsql-bugs
From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: icegood1980(at)gmail(dot)com
Subject: BUG #15627: libpq memory leak
Date: 2019-02-10 16:30:29
Message-ID: 15627-292cee37a2b87e13@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 15627
Logged by: ice ice
Email address: icegood1980(at)gmail(dot)com
PostgreSQL version: 11.1
Operating system: Ubuntu 18.04.1 LTS
Description:

PQisBusy has memory leak with next valgrind stack:

1: malloc in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
2: PQmakeEmptyPGresult in
/opt/src/postgres/src/interfaces/libpq/fe-exec.c:146
3: getRowDescriptions in
/opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:492
4: pqParseInput3 in
/opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:293
5: parseInput in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1747
6: PQisBusy in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1764

The problem is that if PQisBusy doesn't revoke memory for item

/* Status for asynchronous result construction */
PGresult *result; /* result being constructed */

in struct pg_conn


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: icegood1980(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15627: libpq memory leak
Date: 2019-02-10 17:03:07
Message-ID: 25171.1549818187@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: Postg토토 사이트 추천SQL : Postg토토 사이트 추천SQL 메일 링리스트 : 2019-02-10 이후 PGSQL-BUGS 17:03

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> PQisBusy has memory leak with next valgrind stack:

> 1: malloc in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
> 2: PQmakeEmptyPGresult in
> /opt/src/postgres/src/interfaces/libpq/fe-exec.c:146
> 3: getRowDescriptions in
> /opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:492
> 4: pqParseInput3 in
> /opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:293
> 5: parseInput in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1747
> 6: PQisBusy in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1764

I don't believe this is actually a leak: what is happening is that
we're collecting the query result that will eventually be returned
by PQgetResult. If the calling program never calls PQgetResult
after PQisBusy, then tools like valgrind might claim that's a leak,
but the claim has nothing to do with reality.

If you think there's a real problem here, please show a self-contained
test case that causes steady increase in memory consumption.

regards, tom lane


From: Sergey Ivanov <icegood1980(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15627: libpq memory leak
Date: 2019-02-10 21:20:32
Message-ID: CAJCbrz47ex2LD3AXXi=xZUxh2jJsnzseHrW_vCY8qh+z7f3amg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

Thanks Tom. My fault. Hasn't closed PGRES_TUPLES_OK last empty record in
single row mode output

вс, 10 февр. 2019 г. в 19:03, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > PQisBusy has memory leak with next valgrind stack:
>
> > 1: malloc in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
> > 2: PQmakeEmptyPGresult in
> > /opt/src/postgres/src/interfaces/libpq/fe-exec.c:146
> > 3: getRowDescriptions in
> > /opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:492
> > 4: pqParseInput3 in
> > /opt/src/postgres/src/interfaces/libpq/fe-protocol3.c:293
> > 5: parseInput in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1747
> > 6: PQisBusy in /opt/src/postgres/src/interfaces/libpq/fe-exec.c:1764
>
> I don't believe this is actually a leak: what is happening is that
> we're collecting the query result that will eventually be returned
> by PQgetResult. If the calling program never calls PQgetResult
> after PQisBusy, then tools like valgrind might claim that's a leak,
> but the claim has nothing to do with reality.
>
> If you think there's a real problem here, please show a self-contained
> test case that causes steady increase in memory consumption.
>
> regards, tom lane
>

--
Kind regards,
Sergey Ivanov