Re: Detecting use-after-free bugs using gcc's malloc() attribute

On 26.06.23 21:54, Andres Freund wrote:
> For something like pg_list.h the malloc(free) attribute is a bit awkward to
> use, because one a) needs to list ~30 functions that can free a list and b)
> the referenced functions need to be declared.

Hmm.  Saying list_concat() "deallocates" a list is mighty confusing 
because 1) it doesn't, and 2) it might actually allocate a new list.  So 
while you get the useful behavior of "you probably didn't mean to use 
this variable again after passing it into list_concat()", if some other 
tool actually took these allocate/deallocate decorations at face value 
and did a memory leak analysis with them, they'd get completely bogus 
results.

> I also added such attributes to bitmapset.h and palloc() et al, but that
> didn't find existing bugs.  It does find use-after-free instances if I add
> some, similarly it does find cases of mismatching palloc with free etc.

This seems more straightforward.  Even if it didn't find any bugs, I'd 
imagine it would be useful during development.

> Do others think this would be useful enough to be worth polishing? And do you
> agree the warnings above are bugs?

I actually just played with this the other day, because I can never 
remember termPQExpBuffer() vs. destroyPQExpBuffer().  I couldn't quite 
make it work for that, but I found the feature overall useful, so I'd 
welcome support for it.