Re: Clang Address Sanitizer (Postgres14) Detected Memory Leaks

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Clang Address Sanitizer (Postgres14) Detected Memory Leaks
Date: 2020-08-27 16:54:19
Message-ID: CAEudQArk2sAJfqxY0Y18u1EVkher0COMgduTbZcfLXuhDyagVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qui., 27 de ago. de 2020 às 12:46, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> writes:
> > Is this something to worry about, or is it another problem with the
> > analysis tool, that nobody cares about?
>
> As far as the first one goes, I'd bet on buggy analysis tool.
> The complained-of allocation is evidently for the "extra" state
> associated with the timezone GUC variable, and AFAICS guc.c is
> quite careful not to leak those. It is true that the block will
> still be allocated at process exit, but that doesn't make it a leak.
>
> I did not trace the second one in any detail, but I don't believe
> guc.c leaks sourcefile strings either. There's only one place
> where it overwrites them, and that place frees the old value.
>
> If these allocations do genuinely get leaked in some code path,
> this report is of exactly zero help in finding where; and I'm
> afraid I'm not very motivated to go looking for a bug that probably
> doesn't exist.
>
Hi Tom,
thanks for taking a look at this.

I tried to find where the zone table is freed, without success.
It would be a big surprise for me, if this tool is buggy.
Anyway, it's just a sample of the total report, which is 10 mb
(postmaster.log), done with the regression tests.

regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-08-27 16:57:20 Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
Previous Message Tom Lane 2020-08-27 16:16:22 Re: Deprecating postfix and factorial operators in PostgreSQL 13