This is why tools like valgrind are indispensable. You can run your target process through your test suite with valgrind (or apple’s Instruments) and it’ll tell you if any memory leaked. Even if it’s just a few bytes.
One way is the classic where you get memory from an OS call, and then you lose the pointer to it. Valgrind will then correctly tell you that there's this memory that your app can no longer access.
But you can also simply use more and more memory without losing track of where it is. Say you have some function that gets a new piece of memory and then stores the pointer, again and again. Such a program isn't leaking memory in the classic sense, but it's still using more and more memory. Your tool won't know that this isn't supposed to be happening.
IIRC a common way to leak memory the second way is in GC'ed programs where for instance you might have a closure that owns the pointer, thus the GC when it's marking the objects does not think it needs to clean up the object at the next sweep.
That's usually called a space leak, distinguishing space-wasting program logic from explicit memory mismanagement. Users of a program generally can't distinguish space leak from memory leak, unless you inspect the heap to look for growing chains or pools of similar objects.
I don't know if Valgrind (or Clang msan) would catch this bug as it might not be associated with any calls to *alloc/mmap/free/etc. Seems like a kernel issue, and I don't know if Valgrind has the capability to peer that deep.
