Re: Add malloc attribute to memory allocation functions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Add malloc attribute to memory allocation functions
Date
Msg-id 2248c1c4-68f7-46dc-9e58-9ba9057da74e@eisentraut.org
Whole thread
In response to Re: Add malloc attribute to memory allocation functions  ("Tristan Partin" <tristan@partin.io>)
Responses Re: Add malloc attribute to memory allocation functions
Re: Add malloc attribute to memory allocation functions
List pgsql-hackers
On 06.07.26 18:34, Tristan Partin wrote:
> On Mon Jul 6, 2026 at 4:26 AM UTC, Tom Lane wrote:
>> "Tristan Partin" <tristan@partin.io> writes:
>>> Given that we now have a tree that compiles fine against
>>> -Werror=mismatched-dealloc, we need to make sure that we don't regress.
>>> By adding the malloc attribute[0], we can protect against regressions,
>>> enable more accurate code coverage with -fanalyzer, and allow the
>>> compiler to do some optimizations.
>>
>> 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.
>>
>> (This opinion is based on years of dismissing useless Coverity
>> warnings of this kind.)
> 
> This is a fair criticism. On master, the number of
> -Wanalyzer-malloc-leak warnings is 62. With this patch applied, it
> balloons to 598.

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.




pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded
Next
From: Shinya Kato
Date:
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples