help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: std::string memory leak?


From: Carlos Martinez
Subject: Re: std::string memory leak?
Date: 15 Feb 2007 23:50:58 -0800
User-agent: G2/1.0

On 15 feb, 16:40, Paul Pluzhnikov <ppluzhnikov-...@charter.net> wrote:
> "Carlos Martinez" <carlos.mt...@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?

The OS is Redhat Enterprise 3.0 (with kernel 2.4.21)
Gcc version 3.2.3
The purify report:
         MLK: 1480 bytes leaked at 0x8967b18
         This memory was allocated from:
               malloc         [rtlib.o]
               operator new( unsigned) [new_op.cc:48]
               std::__default_alloc_template<true,
(int)0>::_S_chunk_alloc( unsigned, int &) [stl_alloc.h:108]
               std::__default_alloc_template<true,
(int)0>::_S_refill( unsigned) [stl_alloc.h:550]
               std::__default_alloc_template<true,
(int)0>::allocate( unsigned) [stl_alloc.h:357]
               std::string<char, std::char_traits<char>,
std::allocator<char>>::_Rep::_S_create( unsigned,std::allocator< char>
const &) [stl_alloc.h:673]
               char * std::string<char, std::char_traits<char>,
std::allocator<char>>::_S_construct< char const *>( char const *, char
const *,std::allocator< char> const &,std::forward_iterator_tag)
[basic_string.tcc:150]
               std::string<char, std::char_traits<char>,
std::allocator<char>>::string<char, std::char_traits<char>,
std::allocator<char>>( char const *, unsigned,std::allocator< char>
const &) [basic_string.h:668]
               ContenidosValorados::WField<std::string<char,
std::char_traits<char>, std::allocator<char>>,AsnOcts
*,true>::operator =(AsnOcts const *) [ifzWTarifCV.h:225]
 
ContenidosValorados::WCobroDirectoReq::copiarDeAsn(AsnType const &)
[ifzWTarifCV.cc:569]

The problem is at this sentence:

return operator=(String(*src,src->Len()));

I'm calling another version of operator= of the same class (WField),
but passing to it a String, instead of an AsnOcts. For doing that, I
construct a temporary String, and there is where memory leak appears.
String is a typedef for std::string (because I'm testing with
different string classes for locating the memory leak)

> >> 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!]

My gcc version is 3.2.3
I test with GLIBCPP_FORCE_NEW and GLIBCXX_FORCE_NEW, but it leaks
memory.

> >> 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 program is single-threaded.

> > 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,

Thanks



reply via email to

[Prev in Thread] Current Thread [Next in Thread]