https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2017-05-08
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Bernd Paysan from comment #0)
> This not very friendly blog entry contains a report of a memory leak in
> libstdc++ ("worst bug of my entire career"):
>
> https://www.zerotier.com/blog/2017-05-05-theleak.shtml
>
> Including a not very easy way to reproduce it (by installing their software
> and stress-testing it). Apparently he didn't file a bug report here.
No, and that blog post is full of incorrect statements like "libstdc++
"helpfully" adds its own memory allocator layer between you and the C library.
This one implements its own caching and pooling, and searching around the web
yields many examples of people complaining about it."
That's simply not true. In the default configuration of libstdc++,
std::allocator uses new/delete and which just call malloc/free. There's no
caching and pooling at all.
> Solution proposed there: link against jemalloc (it's under BSDL),
> performance goes up, memory consumption stays low, i.e. neither use glibc's
> "too slow" malloc() nor use libstdc++'s memory allocator (still slower than
> jemalloc).
No, that's not what it says:
"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.
> Due to #1, we don't even know how many people are affected by the bug.
What bug?
