Wow. This is worth a Linus Torvalds-level rant. Whoever accepted this code into the source tree needs to be put on GNU's version of a performance improvement plan.
This is also why Valgrind separates reachable and unreachable memory and only considers unreachable memory as leaks.
In any case, hiding this sort of behavior in a way that sucks down days of debugging time on the part of one expert programmer after another, after another, after another, is terrible engineering.
On iOS and android you are expected to free whatever unused memory you can when you are notified of a low memory situation.
So it's not a traditional leak but because memory usage would continue to grow it causes the long lived process to choke itself and die.
 And you cannot have more than one heap without mmap. Without mmap, you only have sbrk = the one heap. On UNIX and those that pretend to be, anyway.
> On most operating systems, memory allocated to a program can never be returned to the system. ... Some operating systems (notably, systems that use mmap(2) for allocating large chunks of memory) can reclaim memory that is no longer used ...
Because you can't return unneeded memory to most operating systems (or because it used to be that you couldn't return unneeded memory, even if that has changed recently), it isn't a surprise that by default GCC's free() and operator delete -- which are meant to be cross platform -- don't try to return that memory. Instead it's all free list management.
I do think it's silly for operators new/delete to have a separate free list from malloc()/free().
They don't. This is a custom, simple, non-default pool allocator for standard containers (i.e nothing to do with new)
It's especially silly for a library (programs may want custom memory management and libraries really shouldn't go out of their way to make that harder), and the fact that it's the standard library doesn't make it less silly.