Re: Add counted_by attribute

On Wed Aug 5, 2026 at 4:05 PM UTC, Peter Eisentraut wrote:
> On 30.07.26 00:07, Tristan Partin wrote:
>> The counted_by[0] compiler attribute is fairly new. It was added in GCC
>> 15 and Clang 18. It has been used fairly extensively in the Linux
>> kernel[0].
>>
>> To summarize the benefits of the attribute:
>>
>> - Runtime bounds checking with -DFORTIFY_SOURCE=3 and -fsanitize-bounds
>> - Accurate reporting of __builtin_dynamic_object_size()
>>
>> While we don't use __builtin_dynamic_object_size(), I think the runtime
>> bounds checking improvements are easily worth the little bit of effort
>> to add the attribute in various locations and review the code. I think
>> it will improve things for buildfarm animals using ASan due to expanded
>> coverage.
>
> I think this is a good idea.
>
> Maybe you could produce an intentionally broken piece of code that would
> illustrate what kinds of reports one might hope to get from this.

Sure. I'll share three examples.

Back in 2022, Tom committed a fix for an off by one error:
a36196972b[0]. Assuming we had an animal configured for
-fsanitize=address, and the accompanying diff (logical-replication.diff)
applied, we could have probably done a better job at avoiding this
mistake in the first place. The animal would have rightfully complained
about this mistake.

Another example: TupleDescCompactAttr() is called into over 100 times
and takes an index into the TupleDesc::compact_attrs array. That
function does not contain an Assert() for checking if the index is
actually valid. An errant caller could easily cause a SIGSEGV or we
could reach into uninitialized memory. In the supplied diff
(tuple.diff), I added the counted_by attribute, which would allow us to
fail loudly if an animal was configured with -fsanitize=address. I also
went ahead and also added an Assert() just to be safe.

To give a more concrete example, I have attached a C file that has
a similar off by one mistake to the one that Tom fixed. You can compile
it with the following command line:

gcc -fsanitize=address test.c

And if you run it (./a.out), you will see something like the following:

$ ./a.out
0
0
0
=================================================================
==1651747==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7bf02dde001c at pc 0x55d9fecc52a2 bp 0x7ffcaf3ff4a0 sp 0x7ffcaf3ff498
READ of size 4 at 0x7bf02dde001c thread T0
#0 0x55d9fecc52a1 in main (/local/home/dbltap/Projects/postgres/counted_by/a.out+0x12a1)
#1 0x7fd02ee2b284 in __libc_start_call_main (/nix/store/qqiqd3ah10x8hzsif4j1y4xc1miw23nx-glibc-2.42-67/lib/libc.so.6+0x2b284) (BuildId: c38f504d883365a4836730fb07e9269ade763988)
#2 0x7fd02ee2b337 in __libc_start_main(at)GLIBC_2(dot)2(dot)5 (/nix/store/qqiqd3ah10x8hzsif4j1y4xc1miw23nx-glibc-2.42-67/lib/libc.so.6+0x2b337) (BuildId: c38f504d883365a4836730fb07e9269ade763988)
#3 0x55d9fecc50e4 in _start (/local/home/dbltap/Projects/postgres/counted_by/a.out+0x10e4)

0x7bf02dde001c is located 0 bytes after 12-byte region [0x7bf02dde0010,0x7bf02dde001c)
allocated by thread T0 here:
#0 0x7fd02f32be4f in calloc (/nix/store/lv6lq05xay6zr2lbchz47zs8yrza3y86-gcc-16.2.0-lib/lib/libasan.so.8+0x12be4f)
#1 0x55d9fecc524a in main (/local/home/dbltap/Projects/postgres/counted_by/a.out+0x124a)
#2 0x7fd02ee2b284 in __libc_start_call_main (/nix/store/qqiqd3ah10x8hzsif4j1y4xc1miw23nx-glibc-2.42-67/lib/libc.so.6+0x2b284) (BuildId: c38f504d883365a4836730fb07e9269ade763988)
#3 0x7fd02ee2b337 in __libc_start_main(at)GLIBC_2(dot)2(dot)5 (/nix/store/qqiqd3ah10x8hzsif4j1y4xc1miw23nx-glibc-2.42-67/lib/libc.so.6+0x2b337) (BuildId: c38f504d883365a4836730fb07e9269ade763988)
#4 0x55d9fecc50e4 in _start (/local/home/dbltap/Projects/postgres/counted_by/a.out+0x10e4)

[0]: https://github.com/postgres/postgres/commit/a36196972b

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)