Horton

Thread

Commits

  1. Fix memory leaks in error reporting with LOG level

  1. Fix resource leak (src/backend/libpq/be-secure-common.c)

    Ranier Vilela <ranier.vf@gmail.com> — 2024-04-02T18:13:19Z

    Hi,

Per Coverity.

Coverity reported a resource leak at the function
run_ssl_passphrase_command.
7. alloc_fn: Storage is returned from allocation function
wait_result_to_str.["show details"]

8. noescape: Assuming resource wait_result_to_str(pclose_rc) is not freed
or pointed-to as ellipsis argument to errdetail_internal.

CID 1533043: (#1 of 1): Resource leak (RESOURCE_LEAK)
9. leaked_storage: Failing to save or free storage allocated by
wait_result_to_str(pclose_rc) leaks it.

I think that Coverity is right.

Fix by freeing the pointer, like pclose_check (src/common/exec.c) similar
case.

Patch attached.

best regards,

  2. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Daniel Gustafsson <daniel@yesql.se> — 2024-04-02T18:31:48Z

    > On 2 Apr 2024, at 20:13, Ranier Vilela <ranier.vf@gmail.com> wrote:

> Fix by freeing the pointer, like pclose_check (src/common/exec.c) similar case.

Off the cuff, seems reasonable when loglevel is LOG.

--
Daniel Gustafsson

  3. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Ranier Vilela <ranier.vf@gmail.com> — 2024-04-10T18:31:02Z

    Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson <daniel@yesql.se>
escreveu:

> > On 2 Apr 2024, at 20:13, Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> > Fix by freeing the pointer, like pclose_check (src/common/exec.c)
> similar case.
>
> Off the cuff, seems reasonable when loglevel is LOG.
>

Per Coverity.

Another case of resource leak, when loglevel is LOG.
In the function shell_archive_file (src/backend/archive/shell_archive.c)
The pointer *xlogarchcmd*  is not freed.

best regards,
Ranier Vilela

  4. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Daniel Gustafsson <daniel@yesql.se> — 2024-04-10T18:33:03Z

    > On 10 Apr 2024, at 20:31, Ranier Vilela <ranier.vf@gmail.com> wrote:
> 
> Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> escreveu:
>> > On 2 Apr 2024, at 20:13, Ranier Vilela <ranier.vf@gmail.com <mailto:ranier.vf@gmail.com>> wrote:
>> 
>> > Fix by freeing the pointer, like pclose_check (src/common/exec.c) similar case.
>> 
>> Off the cuff, seems reasonable when loglevel is LOG.
> 
> Per Coverity.
> 
> Another case of resource leak, when loglevel is LOG.
> In the function shell_archive_file (src/backend/archive/shell_archive.c)
> The pointer *xlogarchcmd*  is not freed.

Thanks, I'll have a look.  I've left this for post-freeze on purpose to not
cause unnecessary rebasing.  Will take a look over the next few days unless
beaten to it.

--
Daniel Gustafsson

  5. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Ranier Vilela <ranier.vf@gmail.com> — 2024-05-13T18:05:32Z

    Em qua., 10 de abr. de 2024 às 15:33, Daniel Gustafsson <daniel@yesql.se>
escreveu:

> On 10 Apr 2024, at 20:31, Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson <daniel@yesql.se>
> escreveu:
>
>> > On 2 Apr 2024, at 20:13, Ranier Vilela <ranier.vf@gmail.com> wrote:
>>
>> > Fix by freeing the pointer, like pclose_check (src/common/exec.c)
>> similar case.
>>
>> Off the cuff, seems reasonable when loglevel is LOG.
>>
>
> Per Coverity.
>
> Another case of resource leak, when loglevel is LOG.
> In the function shell_archive_file (src/backend/archive/shell_archive.c)
> The pointer *xlogarchcmd*  is not freed.
>
>
> Thanks, I'll have a look.  I've left this for post-freeze on purpose to not
> cause unnecessary rebasing.  Will take a look over the next few days unless
> beaten to it.
>
Any chance we'll have these fixes in v17?

best regards,
Ranier Vilela

  6. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Daniel Gustafsson <daniel@yesql.se> — 2024-05-13T18:06:57Z

    > On 13 May 2024, at 20:05, Ranier Vilela <ranier.vf@gmail.com> wrote:
> Em qua., 10 de abr. de 2024 às 15:33, Daniel Gustafsson <daniel@yesql.se> escreveu:

> Thanks, I'll have a look.  I've left this for post-freeze on purpose to not
> cause unnecessary rebasing.  Will take a look over the next few days unless
> beaten to it.

> Any chance we'll have these fixes in v17?

Nice timing, I was actually rebasing them today to get them committed.

--
Daniel Gustafsson

  7. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Michael Paquier <michael@paquier.xyz> — 2024-05-14T06:03:22Z

    On Mon, May 13, 2024 at 08:06:57PM +0200, Daniel Gustafsson wrote:
>> Any chance we'll have these fixes in v17?
> 
> Nice timing, I was actually rebasing them today to get them committed.

Looks sensible seen from here, as these paths could use a LOG or rely
on a memory context permanent to the backend causing junk to be
accumulated.  It's not that much, still that would accumulate.
--
Michael

  8. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Daniel Gustafsson <daniel@yesql.se> — 2024-05-14T10:21:31Z

    > On 14 May 2024, at 08:03, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Mon, May 13, 2024 at 08:06:57PM +0200, Daniel Gustafsson wrote:
>>> Any chance we'll have these fixes in v17?
>> 
>> Nice timing, I was actually rebasing them today to get them committed.
> 
> Looks sensible seen from here, as these paths could use a LOG or rely
> on a memory context permanent to the backend causing junk to be
> accumulated.  It's not that much, still that would accumulate.

Pushed.

--
Daniel Gustafsson

  9. Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

    Ranier Vilela <ranier.vf@gmail.com> — 2024-05-14T11:03:57Z

    Em ter., 14 de mai. de 2024 às 07:21, Daniel Gustafsson <daniel@yesql.se>
escreveu:

> > On 14 May 2024, at 08:03, Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Mon, May 13, 2024 at 08:06:57PM +0200, Daniel Gustafsson wrote:
> >>> Any chance we'll have these fixes in v17?
> >>
> >> Nice timing, I was actually rebasing them today to get them committed.
> >
> > Looks sensible seen from here, as these paths could use a LOG or rely
> > on a memory context permanent to the backend causing junk to be
> > accumulated.  It's not that much, still that would accumulate.
>
> Pushed.
>
Thanks Daniel.

best regards,
Ranier Vilela