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.