public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Tristan Partin <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Add malloc attribute to memory allocation functions
Date: Tue, 07 Jul 2026 11:53:36 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Peter Eisentraut <[email protected]> writes:
> On 06.07.26 18:34, Tristan Partin wrote:
>> On Mon Jul 6, 2026 at 4:26 AM UTC, Tom Lane wrote:
>>> I'm skeptical that this is going to lead to anything but grief.
>>> In particular, since gcc has never heard of memory contexts,
>>> I don't see how we are not going to get buried in bogus
>>> -Wanalyzer-malloc-leak warnings.  It doesn't really help
>>> to add compiler annotations that only sort-of match our semantics.

> But this can also check for a lot more, such as
> - mismatching deallocator
> - double free
> - use after free
> - free of things that are not an allocation
> If we could tell it, check for all these things but don't worry about 
> the leaks, that could be useful.

> Also, for frontend tools, libpq, etc. that don't use memory contexts.

Yeah, I was thinking about that last point.  The frontend environment
is a lot closer to the semantics these markers expect, so we could
try doing this in frontend only and see how well that works.

There are still places that I'd expect to be trouble.  For example,
Coverity has never understood the pattern we use in pg_dump's data
collection subroutines, ie, malloc a big array of structs, fill
the individual structs and insert pointers to them into the hash
tables, done.  It always thinks we leaked the array, and I suspect
tools like this will too.  In Coverity's case there's enough
infrastructure to dismiss individual false-positive complaints,
and then it won't bug you about them (until somebody changes the
relevant code enough that the dismissal doesn't match :-().  Unless
there's some similar way to silence individual reports, I don't
foresee tools like this to be usable.  We're not going to change
coding patterns like that one just because some static analyzer
doesn't understand them.

			regards, tom lane

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Add malloc attribute to memory allocation functions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox