3 ms·

Can you link to some of the things you've read? What exactly is the "known issue"?

• MaysonL 9y ago
  From the documentation (linked by arunc above)[0] "Notes about deallocation. This allocator does not explicitly release memory. Because of this, memory debugging programs like valgrind or purify may notice leaks: sorry about this inconvenience. Operating systems will reclaim allocated memory at program termination anyway. If sidestepping this kind of noise is desired, there are three options: use an allocator, like new_allocator that releases memory while debugging, use GLIBCXX_FORCE_NEW to bypass the allocator's internal pools, or use a custom pool datum that releases resources on destruction." [0]https://gcc.gnu.org/onlinedocs/libstdc++/manual/mt_allocator_impl.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/mt_allocator...
  • mjw1007 9y ago
    That doesn't explain the «Some allocations were much larger than anything ZeroTier should need.» part.
    • api 9y ago
      Yes it does. The secondary C++ allocator is doing its own pooling on top of the primary allocator.