Re: std::string memory leak?

[Paul Pluzhnikov]

"Carlos Martinez" <carlos.mtnez@gmail.com> writes:

> On 15 feb, 12:52, "Carlos Martinez" <carlos.mt...@gmail.com> wrote:
>>
>> I have a possible memory leak.
>> I use rational's purify to detect memory leaks, and it indicates a
>> memory leak in a temporary of std::string.

Unfortunately your post lacks all the relevant details which may
have helped answering your question: what OS, what version of gcc,
what is the actual Purify report?

>> I have read somewhere that some memory leaks aren't memory leaks at
>> all. It seams it could be the memory pool used by the stl.
>> I have test with and without GLIBCPP_FORCE_NEW environment variable
>> enabled, and in both cases there is the memory leak.

Which environment variable you must use depends on version of gcc:
For 2.9x, recompile code with -D__USE_MALLOC.
For gcc versions between 3.0 and 3.3.1 there is no variable you
can set (AFAICT).
For gcc 3.3.2 the variable is GLIBCPP_FORCE_NEW 
For gcc 3.4.0 and above it is GLIBCXX_FORCE_NEW
[What a mess!]

>> I assume it's a memory leak, because without purify, processes grows
>> up in memory usage indefinitely  and because if I change std::string
>> for my own very, very basic implementation of string, it disappears
>> (no memory growth nor memory leak indication by purify)

One of the reasons std::string may leak is if multi-threaded code
is compiled incorrectly. Is your code mutithreaded, and what is
the compilation command line?

> The process, processes operations, and even all operations are the
> same, not always appears memory leak. This suggest, there isn't a
> memory leak and enforce the theroy of a memory pool consecuence, but i
> don't understand it because process in memory grows indefinitely if i
> use std::string

If the code is multi-threaded, then "irreproducible results" fit the
"incorrect compilation theory".

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.