Horton

Thread

Commits

  1. Avoid memory leak in rmtree() when path cannot be opened

  1. Avoid possible memory leak (src/common/rmtree.c)

    Ranier Vilela <ranier.vf@gmail.com> — 2023-07-25T14:31:05Z

    Hi,

Per Coverity.

rmtree function can leak 64 bytes per call,
when it can't open a directory.

patch attached.

best regards,
Ranier Vilela

  2. Re: Avoid possible memory leak (src/common/rmtree.c)

    Daniel Gustafsson <daniel@yesql.se> — 2023-07-25T14:45:22Z

    > 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

  3. Re: Avoid possible memory leak (src/common/rmtree.c)

    Michael Paquier <michael@paquier.xyz> — 2023-07-29T02:54:48Z

    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

  4. Re: Avoid possible memory leak (src/common/rmtree.c)

    Ranier Vilela <ranier.vf@gmail.com> — 2023-07-31T23:10:55Z

    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

  5. Re: Avoid possible memory leak (src/common/rmtree.c)

    Michael Paquier <michael@paquier.xyz> — 2023-07-31T23:56:08Z

    On Mon, Jul 31, 2023 at 08:10:55PM -0300, Ranier Vilela wrote:
> Thanks for the commit, Michael.

Sorry for the lack of update here.  For the sake of the archives, this
is f1e9f6b.
--
Michael