Re: BUG #16348: Memory leak when parsing config

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: hghwng(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16348: Memory leak when parsing config
Date: 2020-04-07 15:22:28
Message-ID: 29582.1586272948@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> ANALYSIS:
> When parsing config file, gui-file.l:ProcessConfig sets up memory context.
> It invokes guc-file.l:ProcessConfigFileInternal, which is expected to leak
> memory. It's okay because the leaked memory will be freed when cleaning up
> the context. Next, guc-file.l:ProcessConfigFileInternal associates each
> config item with filename by calling guc.c:set_config_option, which calls
> guc.c:guc_strdup. However, guc.c:guc_strdup is not aware of the memory
> context, and invokes libc.so:strdup directly.

And?

The places that use guc_strdup are expecting that the values will be
tracked and then freed when discarded. Perhaps there is a code path
where that's not happening, but you haven't either shown it or given
any reason to believe one exists.

As a quick cross-check, I set up a shell loop to send a constant stream
of SIGHUPs to an idle backend. I don't see any change in the backend's
memory consumption in "top". Maybe this test case is missing some
necessary factor ... but, again, you haven't given a reason to believe
there is one.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Fujii Masao 2020-04-07 16:49:27 Re: Don't try fetching future segment of a TLI.
Previous Message Jehan-Guillaume de Rorthais 2020-04-07 15:17:36 Re: [BUG] non archived WAL removed during production crash recovery