Thread: BUG #15627: libpq memory leak
The following bug has been logged on the website: Bug reference: 15627 Logged by: ice ice Email address: icegood1980@gmail.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
PG Bug reporting form <noreply@postgresql.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
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@sss.pgh.pa.us>:
PG Bug reporting form <noreply@postgresql.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
Sergey Ivanov