Avoid possible memory leak (src/common/rmtree.c)
Hi,
Per Coverity.
rmtree function can leak 64 bytes per call,
when it can't open a directory.
patch attached.
best regards,
Ranier Vilela
Attachments:
0003-Avoid-possible-memory-leak-64-bytes-per-rmtree-call-.patchapplication/octet-stream; name=0003-Avoid-possible-memory-leak-64-bytes-per-rmtree-call-.patchDownload
From bcdfcbc9b85bf8e0e7c6693a837513e68008f9d2 Mon Sep 17 00:00:00 2001
From: Ranier Vilela <ranier.vf@gmail.com>
Date: Tue, 25 Jul 2023 09:21:34 -0300
Subject: [PATCH 3/4] Avoid possible memory leak (64 bytes) per rmtree call,
when can't open a directory.
Per Coverity.
Author: Ranier Vilela (ranier.vf@gmail.com)
---
src/common/rmtree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/common/rmtree.c b/src/common/rmtree.c
index cd99d3f471..0fdc28fb7f 100644
--- a/src/common/rmtree.c
+++ b/src/common/rmtree.c
@@ -55,7 +55,7 @@ rmtree(const char *path, bool rmtopdir)
bool result = true;
size_t dirnames_size = 0;
size_t dirnames_capacity = 8;
- char **dirnames = palloc(sizeof(char *) * dirnames_capacity);
+ char **dirnames;
dir = OPENDIR(path);
if (dir == NULL)
@@ -64,6 +64,7 @@ rmtree(const char *path, bool rmtopdir)
return false;
}
+ dirnames = (char **) palloc(sizeof(char *) * dirnames_capacity);
while (errno = 0, (de = readdir(dir)))
{
if (strcmp(de->d_name, ".") == 0 ||
--
2.32.0.windows.1
On 25 Jul 2023, at 16:31, Ranier Vilela <ranier.vf@gmail.com> wrote:
rmtree function can leak 64 bytes per call,
when it can't open a directory.
Skimming the tree there doesn't seem to be any callers which aren't exiting or
ereporting on failure so the real-world impact seems low. That being said,
silencing static analyzers could be reason enough to delay allocation.
--
Daniel Gustafsson
On Tue, Jul 25, 2023 at 04:45:22PM +0200, Daniel Gustafsson wrote:
Skimming the tree there doesn't seem to be any callers which aren't exiting or
ereporting on failure so the real-world impact seems low. That being said,
silencing static analyzers could be reason enough to delay allocation.
A different reason would be out-of-core code that uses rmtree() in a
memory context where the leak would be an issue if facing a failure
continuously? Delaying the allocation after the OPENDIR() seems like
a good practice anyway.
--
Michael
Em sex, 28 de jul de 2023 11:54 PM, Michael Paquier <michael@paquier.xyz>
escreveu:
On Tue, Jul 25, 2023 at 04:45:22PM +0200, Daniel Gustafsson wrote:
Skimming the tree there doesn't seem to be any callers which aren't
exiting or
ereporting on failure so the real-world impact seems low. That being
said,
silencing static analyzers could be reason enough to delay allocation.
A different reason would be out-of-core code that uses rmtree() in a
memory context where the leak would be an issue if facing a failure
continuously? Delaying the allocation after the OPENDIR() seems like
a good practice anyway.
Thanks for the commit, Michael.
best regards,
Ranier Vilela