Re: std::string memory leak?

[Paul Pluzhnikov]

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

> The OS is Redhat Enterprise 3.0 (with kernel 2.4.21)
> Gcc version 3.2.3

It's unlikely that you have "straight" gcc-3.2.3. 

More likely you have
  gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)
or some such. RedHat often applies patches, so it may be important
to know *exactly* what compiler you have.

> The purify report:
>          MLK: 1480 bytes leaked at 0x8967b18
>          This memory was allocated from:
>                malloc         [rtlib.o]
>                operator new( unsigned) [new_op.cc:48]

This isn't a complete purify report.
What you don't show may provide important clues.

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

It's a pretty safe bet that std::string does *not* leak.
You really ought to examine the object that "owns" the resulting
string. For example, the test case below "leaks" 2 chunks of memory,
the larger one comes from std::string, and the smaller one from
"user code". But it is the user code that is causing both leaks.

--- cut ---
#include <string>

using namespace std;

struct Foo {
   Foo(const string& s) : s_(s) { }
   string s_;
};

// generate large string
string fun()
{
    string res;
    res.reserve(2000);
    res += "abcd";
    return res;
}

int main()
{
    if (1) {
        Foo *f = new Foo(fun());
    } // "f" leaked here
    return 0;
}
--- cut ---

Here is abridged leak report from Insure++ for the above ...

Leaks detected at exit
----------------------
      2032 bytes 1 chunk allocated at new_allocator.h, 81
                          malloc()  (interface)
                    operator new()  new, 48
    std::string::_Rep::_S_create()  new_allocator.h, 81
     std::string::_Rep::_M_clone()  basic_string.tcc, 561
            std::string::reserve()  basic_string.h, 269
                             fun()  string-leak.cpp, 14
                            main()  string-leak.cpp, 22

         4 bytes 1 chunk allocated at string-leak.cpp, 22
                          malloc()  (interface)
                    operator new()  new, 48
                            main()  string-leak.cpp, 22

If you were to concentrate on the larger leak, you'd think that
std::string is leaking, but the ultimate culprit is the 4-byte leak
on line 22, and the 'std::string::reserve()' is a "red herring".

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