Re: Fix some memory leaks in ecpg.addons

Hi,

On 2023-11-08 11:37:46 -0600, Tristan Partin wrote:
> On Wed Nov 8, 2023 at 11:18 AM CST, Michael Meskes wrote:
> > Am Mittwoch, dem 08.11.2023 um 12:07 -0500 schrieb Tom Lane:
> > > "Tristan Partin" <tristan(at)neon(dot)tech> writes:
> > > > clang and gcc both now support -fsanitize=address,undefined. These
> > > > are > > really useful to me personally when trying to debug issues.
> > > > Unfortunately ecpg code has a ton of memory leaks, which makes
> > > > builds > > really painful. It would be great to fix all of them, but
> > I don't
> > > > have > > the patience to try to read flex/bison code. Here are two
> > memory
> > > > leak > > fixes in any case.
> > > > I'm kind of failing to see the point.  As you say, the ecpg
> > > preprocessor leaks memory like there's no tomorrow.  But given its
> > > usage (process one source file and exit) I'm not sure that is worth
> > > much effort to fix.  And what does it buy to fix just two spots?
> >
> > Agreed, it's not exactly uncommon for tools like ecpg to not worry
> > about memory. After all it gets freed when the program ends.
>
> In the default configuration of AddressSanitizer, I can't even complete a
> full build of Postgres.

I don't find the leak checks very useful for the moment. Leaks that happen
once in the lifetime of the program aren't problematic, and often tracking
them would make code more complicated. Perhaps we'll eventually change our
tune on this, but I don't think it's worth fighting this windmill at this
point. I think at the very least we'd first want to port the memory context
infrastructure to frontend programs.

>
> Are people using some suppression file or setting ASAN_OPTIONS to something?

You pretty much have to. Locally I use this:

export ASAN_OPTIONS='debug=1:print_stacktrace=1:disable_coredump=0:abort_on_error=1:detect_leaks=0:detect_stack_use_after_return=0' UBSAN_OPTIONS='print_stacktrace=1:disable_coredump=0:abort_on_error=1'

CI uses something similar.

Greetings,

Andres Freund