[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #16 from Jonathan Wakely --- Yes, mt allocator has problems, that's why we stopped using it in 2005, but the zerotier code isn't even using mt allocator. Their problem is probably something different. That's the problem with writing ghost stories instead of bug reports: ghosts aren't real.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 Jonathan Wakely changed: What|Removed |Added Version|5.0 |unknown --- Comment #15 from Jonathan Wakely --- (In reply to Bernd Paysan from comment #14) > I therefore assigned that bug to libstdc++ version 5.0. Um no, it was changed more than ten years ago.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 Bernd Paysan changed: What|Removed |Added Version|unknown |5.0 --- Comment #14 from Bernd Paysan --- (In reply to Jonathan Wakely from comment #13) > No libstdc++ bug here, nothing to see, move along. Haha. So I sum up: mt_allocator was made non-default after Version 5.x. Don't use mt_allocator. We know it's not good enough, but won't fix it. Work on improving glibc's malloc is on-going. I therefore assigned that bug to libstdc++ version 5.0. I'm sorry for the time wasted, but I think it is necessary to squish out that sort of bug, whether real or ghost. And the misleading documentation was also fixed.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #13 from Jonathan Wakely --- Like most ghost stories, this one is based on superstition and fantasy, not facts or science: https://www.reddit.com/r/programming/comments/69g8il/the_horror_in_the_standard_library/dhb2las/ No libstdc++ bug here, nothing to see, move along.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #12 from Jonathan Wakely --- (In reply to Bernd Paysan from comment #11) > My guess. He mentions that he's not a lone wolf coder, and since he didn't > understand why mt_allocator was active, I guessed that a coworker had > enabled it ;-). There's no trace at all of ext/mt_allocator in the source > code on github, but in a crappy project, you never know if they build from > the sources they released to github. Yeah I checked that too. > However, with the CPP/CXX change of the environment variable: The minimal > GCC version that builds this project is GCC 4.9... or clang 3.9, which it > prefers to use on build if both gcc and clang are available. So it can't > use a too old libstdc++. In which case using GLIBCXX_FORCE_NEW means they are intentionally switching to a custom allocator in production without testing if it works, and then blaming libstdc++. Or they're linking to some 3rd party library build with an ancient libstdc++. Or setting the env var was just voodoo and didn't change anything in libstdc++. So I still see nothing close to a useful bug report, and I've wasted several hours that could have been spent fixing real bugs in the current codebase.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #11 from Bernd Paysan --- (In reply to Jonathan Wakely from comment #10) > > 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". My guess. He mentions that he's not a lone wolf coder, and since he didn't understand why mt_allocator was active, I guessed that a coworker had enabled it ;-). There's no trace at all of ext/mt_allocator in the source code on github, but in a crappy project, you never know if they build from the sources they released to github. However, with the CPP/CXX change of the environment variable: The minimal GCC version that builds this project is GCC 4.9... or clang 3.9, which it prefers to use on build if both gcc and clang are available. So it can't use a too old libstdc++.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #10 from Jonathan Wakely --- (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.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #9 from Bernd Paysan --- (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, which he need to disable first (after a coworker had enabled it somewhere in the source code): "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." 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).
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #8 from Jonathan Wakely --- (In reply to Bernd Paysan from comment #0) > The documentation of mt_allocator is at least somewhat misleading: > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/mt_allocator_impl.html > > "Notes about deallocation. This allocator does not explicitly release > memory." > > Well, it does add freed memory to its freelists and reuse it. It's just not > giving back unused memory to the OS. I've made a tweak to that text which should clarify things.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > Using the default configuration GLIBCPP_FORCE_NEW has not made any > difference to std::allocator since 2005 when r106665 was committed, changing > the default back to the allocator based on new/delete. In fact that's when the default allocator was switched to new_allocator, but that used GLIBCXX_FORCE_NEW. The older GLIBCPP_FORCE_NEW env var hasn't made a difference since r68958 in 2003.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #6 from Jonathan Wakely --- Using the default configuration GLIBCPP_FORCE_NEW has not made any difference to std::allocator since 2005 when r106665 was committed, changing the default back to the allocator based on new/delete. So if GLIBCPP_FORCE_NEW made a difference then the blog post seems to be about GCC 3.4 or something of that age, and a bug report about ancient history is useless.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #5 from Jonathan Wakely --- Feel free to try to reproduce it or try to contact them. When we have a reproducer, or even a valgrind report, then a bug report might be useful. Until then it's not useful. "I read blog that said there's a bug" is not a bug report.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #4 from Bernd Paysan --- So we close that without having tried to reproduce it? I would have put it into "needinfo" mode, and ask that blog poster to actually fill in the gaps, like "which version of libstdc++", "did you use the default allocator" and such. I lack the information to reproduce it, either. If he doesn't want to cooperate, we can close it as "worksforme".
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Jonathan Wakely --- The blog post links to an unofficial copy of the libstdc++ documentation from 2004, which would explain the bogus claims about libstdc++ allocation policies. I'm going to close this, as I don't feel like wasting time on it. The ZeroTier blog post is simply misinformed and misleading and has no useful information.
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2017-05-08
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
(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?
[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #1 from Marc Glisse --- I am not sure what you expect from this PR exactly. If you have issues about glibc's implementation of malloc, please see about it with glibc (here is for gcc only). They already know about the performance issue, have at least one guy (DJ Delorie) working on it, and he is looking for workloads to help him tune the implementation, search the libc-alpha archives for how to help him. Personal experience: last time I tried jemalloc, it was slower than glibc for my application... If there is still some issue with debugging and multi-threading, try asking them if they have a better idea now of how to implement it. The zerotier rant mixes malloc, new and C++ allocators, it mixes what comes from standard C++ and what is an extension in libstdc++, talks about an environment variable that was renamed in 2003. In the end, it is so far from a useful bug report that I can only ignore it (maybe someone with a lot more time...). Libstdc++ does not create its own allocator by default, it uses new (which maps to malloc) by default. To use something like __mt_alloc, you have to include a header and use something from namespace __gnu_cxx, that's pretty clearly an explicit use of an extension by the user, not the default.
