Re: BUG #16321: Memory leaks in PostmasterMain

On Mon, Mar 30, 2020 at 4:11 AM Hugh Wang <hghwng(at)gmail(dot)com> wrote:
> On Fri, Mar 27, 2020 at 2:52 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>> > The argument parsing duplicates strings, but never frees them.
...
> Your analysis is pretty educational! If the leak is small and has low impact, then the leak itself is not important; yet fixing the bug brings more complexity.

Bear in mind some of this cases are not leaks. You may need the string
live for the whole program lifetime and elect to free them by exiting.

I've had similar cases with a category of my programs which work by
reading many input files and building structures in memory, which I
then use to print some reports. After that I free them by exiting the
program, which is much faster, no leak there. There are a whole lot of
programs which do this, they memory use raises and raises while they
work, and they need all of them, and they free all at once by exiting,
its a valid way to free resources when the only resource is used
memory, the OS frees it on exit.

> However, from the perspective of automated bug finding, I think removing the bug is beneficial. I'm trying to find bugs in PostgreSQL with sanitizers (the leak is reported by LeakSanitizer). If the bug cannot be fixed, LeakSanitizer stops at this shallow point, which prevents detecting more bugs in deep logic.

This may not be a bug. Doesn't leak sanitizer have a way to mark some
data as never freed? A leak is something which you should track and
are not, which may eventually lead to your memory use raising. This
doesn't seem to be the case.

Francisco Olarte.