"Carlos Martinez" <[EMAIL PROTECTED]> 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.
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
