You don't need to wait until program's exit. Valgrind has a GDB server that can be used to check for leaks during program's runtime:

https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mo...

Valgrind has client requests, which you can use to teach it about custom mempools. This should make it possible to avoid the problems this author was having.

See manual chapter 4.7 and 4.8:

https://valgrind.org/docs/manual/mc-manual.html#mc-manual.cl...

The author's definition of a leak is somewhat unusual. If a memory is allocated and eventually freed it's not really a leak in the strict sense. That's why the author is having so much trouble with typical tools like Valgrind or leak sanitizer: the definition of the leak is different!

I would approach this problem by using regular profiling. Collect a few memory profiles and see whether there's any suspiciously large chunk of memory not yet freed.

After a cursory inspection of the memleak program source and Brendan Gregg's blog post it's still not clear to me what it is tracking to be able to decide that there's a leak here. It would seem to me that palloc causes a mmap call for the initial allocation (or to enlarge the region?); but why would an individual allocation within the region be treated as a leak? I can see how eBPF can allow to track mmap usage for custom allocators where valgrind or ASAN might not (I'm not sure about that), but it being reported as a leak would imply that the whole region is missing a deallocation call? How would it recognize via eBPF tracing that 4 KB within the region remain without a pointer?

PS. My assumption here is that palloc is allocating within a region. Which is how OP describes it (oddly it doesn't take a MemoryContext as an argument so that must be in some global or thread-local var, or palloc is a macro and takes the context from a lexical variable (uh)?).

This is pretty interesting. I'm not sure if many commenters have abstracted this approach the way I would have, but it is sure is a handy trick to couple virtual memory related system calls (brk, mmap) to stack dumps and aggregation thereof, and it would not have been so easy to do in, say, 2009.

jemalloc as well has some handy leak / memory profiling abilities: https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-P...

With LSan, you can use __lsan_do_recoverable_leak_check to get leak reports during run time.

Would using Rust have prevented this?