Re: Clang Address Sanitizer (Postgres14) Detected Memory Leaks

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

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-08-27 15:50:56 Re: Should we replace the checks for access method OID with handler OID?
Previous Message Robert Haas 2020-08-27 15:46:09 Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY