Commented by: @AlexPeshkoff

Certainly one can't change Linux behavior regarding splitting VMA (Virtual Memory Area) structures in munmap() call.
What we get with this fix - memory block which can't be unmapped due to ENOMEM error is saved in linked list in MemoryPool and reused as soon as possible. I.e. we avoid throwing exception (which often happens in dtors and therefore highly unliked by c++11) and do not leak memory on this error. Remaining problem is unmapping such memory when firebird dynamic library (i.e. plugin) is unloaded - cleanup code does it's best to unmap linked blocks but if it fails (VMAs allocated by our library are mixed with allocated by others) memory leak appears unavoidable.

Solution was tested artificially reserving most of VMAs using code from https://stackoverflow.com/questions/43743555/munmap-failure-with-enomem-with-private-anonymous-mapping. After applying this fix SC server 2.5 stopped to fail randomly during massive deallocation of memory (was caused stopping TPC-C) and demonstrated stable behavior without memory leaks.