pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedReport a potential memory leak in describeOneTableDetails()
2+ messages / 2 participants
[nested] [flat]
* Report a potential memory leak in describeOneTableDetails()
@ 2022-02-15 02:05 wliang@stu.xidian.edu.cn
0 siblings, 1 reply; 2+ messages in thread
From: wliang@stu.xidian.edu.cn @ 2022-02-15 02:05 UTC (permalink / raw)
To: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Hi all,
I find a potential memory leak in PostgresSQL 14.1, which is in the function describeOneTableDetails (./src/bin/psql/describe.c).
Specifically, at line 1603, a memory chunk is allocated with pg_strdup and assigned to tableinfo.reloptions. If the branch takes true at line 1621, the execution path will eventually jump to error_return at line 3394. Unfortunately, the memory is not freed when the function describeOneTableDetail() returns. As a result, the memory is leaked.
Similarly, the two memory chunks (tableinfo.reloftype and tableinfo.relam) allocated at line 1605, 1606 and 1612 may also be leaked for the same reason.
1355 bool
1356 describeTableDetails(const char *pattern, bool verbose, bool showSystem)
1357 {
...
1603 tableinfo.reloptions = pg_strdup(PQgetvalue(res, 0, 9));
1604 tableinfo.tablespace = atooid(PQgetvalue(res, 0, 10));
1605 tableinfo.reloftype = (strcmp(PQgetvalue(res, 0, 11), "") != 0) ?
1606 pg_strdup(PQgetvalue(res, 0, 11)) : NULL;
...
1610 if (pset.sversion >= 120000)
1611 tableinfo.relam = PQgetisnull(res, 0, 14) ?
1612 (char *) NULL : pg_strdup(PQgetvalue(res, 0, 14));
1613 else
1614 tableinfo.relam = NULL;
...
1621 if (tableinfo.relkind == RELKIND_SEQUENCE)
1622 {
...
1737 goto error_return; /* not an error, just return early */
1738 }
...
3394 error_return:
3395
3396 /* clean up */
3397 if (printTableInitialized)
3398 printTableCleanup(&cont);
3399 termPQExpBuffer(&buf);
3400 termPQExpBuffer(&title);
3401 termPQExpBuffer(&tmpbuf);
3402
3403 if (view_def)
3404 free(view_def);
3405
3406 if (res)
3407 PQclear(res);
3408
3409 return retval;
3410 }
We believe we can fix the problems by adding corresponding release function before the function returns, such as.
if (tableinfo.reloptions)
pg_free (tableinfo.reloptions);
if (tableinfo.reloftype)
pg_free (tableinfo.reloftype);
if (tableinfo.relam)
pg_free (tableinfo. relam);
I'm looking forward to your confirmation.
Best,
Wentao
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Report a potential memory leak in describeOneTableDetails()
@ 2022-02-15 16:36 Tom Lane <tgl@sss.pgh.pa.us>
parent: wliang@stu.xidian.edu.cn
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2022-02-15 16:36 UTC (permalink / raw)
To: wliang@stu.xidian.edu.cn; +Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
wliang@stu.xidian.edu.cn writes:
> I find a potential memory leak in PostgresSQL 14.1, which is in the function describeOneTableDetails (./src/bin/psql/describe.c).
Do you want to submit a patch? The amount of memory involved here isn't
much, but since psql is a potentially long-running program, it seems worth
the trouble to be careful.
I think the best fix might be to drop these strdup's altogether, and
instead postpone freeing the PGresult to the end of the function, so
that we can just use the pointers returned by PQgetvalue.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2022-02-15 16:36 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-02-15 02:05 Report a potential memory leak in describeOneTableDetails() wliang@stu.xidian.edu.cn
2022-02-15 16:36 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox