[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Bernd Paysan from comment #9)
> (In reply to Jonathan Wakely from comment #2)
> > "I dropped in jemalloc and ran the test. CPU usage dropped but otherwise
> > this had no effect."
> > 
> > i.e. jemalloc was not proposed as a solution.
> 
> That's the first attempt, before he discovered that there is another
> allocator (likely mt_alloc) lurking inside,

There is nothing "lurking inside", the author is deeply mistaken that anything
sits between operator new and the C library. The history of operator new can be
seen at
https://gcc.gnu.org/git/?p=gcc.git;a=history;f=libstdc%2B%2B-v3/libsupc%2B%2B/new_op.cc;h=1c19d4477668242eea1803b76e2638fbd699fe92;hb=HEAD
and has been largely unchanged since October 6, 2000.

> which he need to disable first
> (after a coworker had enabled it somewhere in the source code):

Where did you get that information? The blog post says nothing about a coworker
enabling mt_allocator, it strongly implies that the mt allocator pooling is on
by default and is why libstdc++ is "broken".

> "It turns out that there is a somewhat convoluted way to disable it
> globally: set the environment variable "GLIBCPP_FORCE_NEW". After doing
> this, CPU use increased slightly but memory use stabilized. Recalling
> jemalloc I now once again tried sticking it under the controller in place of
> glibc's malloc and both CPU load and memory use dropped to substantially
> less than either stock configuration. More importantly everything became
> stable once again."

Yes I was too busy facepalming by the time I got to the end to notice the
second reference to jemalloc.

> If the "GLIBCPP_FORCE_NEW" is not a typo, we can nail down the version he
> used to somewhere at least 14 years old (because the environment variable is
> now called GLIBCXX_FORCE_NEW).

Right, so unsupported and unmaintained. We're not interested in bug reports for
GCC 3.x or 4.x releases.