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
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 |