This is the mail archive of the
mailing list for the libstdc++ project.
Re: Libstdc++-v3 memory leakage?
>> I think that if this issue can be fixed, and the noise WRT "leaks" goes
>> down, then everybody will be better off. This is what was done WRT locales
>> and io and I think it was a really good idea.
>Sorry, I'm confused. What is the issue? The complete removal of the
>caching pool allocator? ;-)
If that is what you feel is the best option. I would think that
switching defaults, but keeping the old code, might be a better choice.
There have already been a couple of alternate allocators posted, and I
think that work is progressing well.
The "issue" is the generated leak reports that things like valgrind, et.
al., have with the current default allocator. It's confusing to people.
I think that the end goal should be that these very valuable tools
should be able to be used with minimal difficulty with libstdc++-v3.
How that's done (valgrind custom leak supression, documentation, code
changes) is up in the air.
>I'd support changes to the library that mark one-time allocations so
>that valgrind ignores them (or whatever you did to sections of the
I pre-allocated, used placement new. For valgrind, there are other
options. This had the indirect effect of optimizing the allocation path
for the common classes.
>I'd also support Jonathan Wakely updating the documentation before the
>3.3 release (he volunteered in this thread). In particular, I'd love
>a new section:
>How do I check to see if there is a library memory leak with my
>application before I report it? (suggested topics in addition to
>Jonathan's own ideas:)
>-discussion of setting environment variable to disable pool allocator
>-discussion of one-shot code displaying a "leak" doesn't really cut it
> (related to any service in the libary that maintains state or a cache)
>I'd be happy to review and/or commit such improvements to the
see "Tips for memory leak hunting," which obviously needs work.