Re: Make memory checking / sanitizing infrastructure better

On Thu, May 28, 2026 at 9:37 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> I think these aren't actually *that* hard to solve:
>
> 1) The reason we don't always use the sentinel for power-of-two allocations is
> that naively doing so would interfere with the size classing for the
> freelist. But that's relatively easy to address - we can "just" add the
> space for the size classes *after* determining the size class. IIRC we
> used to have a similar issue with the per-allocation chunk header and
> solved it this way too.
>
> 2) We should make make the sentinel size configurable and default to either 8
> or 16 bytes.

+1

>
> 3) I think we should make the memory context failures crash. Perhaps by
> emitting WARNINGs and then crashing if any of them occurred.
>
> As we trigger memory context checking during commit/abort handling, just
> using PANIC won't always reliably work, E.g. the AllocSetCheck() in
> AllocSetReset(), can trigger recursive PANICs due to the
> MemoryContextReset() in errstart(), if the corruption in in ErrorContext.
> Whether that's a real issue worth worrying about, IDK.
>
> 4) For this I prototyped making the valgrind annotations more generic and
> using the address sanitizer interface to mark memory as poisoned /
> unpoisoned. That doesn't provide quite all the checking that valgrind can
> do (it doesn't track uninitialized memory), but it's considerably better
> than our memory context checking, and *much* *much* faster than valgrind.

IIUC, you are proposing to use sanitizer interface to implement
crashing behaviour mentioned in 3? Or these two are separate things?
To me both of them seem to achieve the same end result.

>
> 5) I think we should add a mode to all our allocators that just turns every
> allocation into a large allocation (perhaps with something slightly
> different for slab). In that mode asan, valgrind, et al would be more
> precise. Of course that'll have rather deleterious performance effects,
> but I think it'd still be quite useful for debugging.

I think this has an advantage of its own, we will benefit from memory
sanity check improvements in system calls without necessarily
implementing them in PostgreSQL and also use-after-free failure not
necessarily covered by other proposals.

--
Best Wishes,
Ashutosh Bapat