This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]