memory leak or mtrace()-problem?

[lars.uffmann]

I just reduced a nasty and hard to pin-down memory leak (according to
mtrace() under SuSE 9.3 to a very simple example file and would like to
know what the error is about, and whether it maybe is a bug in the
basic_string-template, or a bug / problem with mtrace, or something
else - and if other people can reproduce it - possibly under
non-SuSE-distributions.

Using g++ to compile memLeak.cpp with gnu c compiler 3.3.5, the
following happens:
-----------
lars@linux:~/test> g++ -o memLeak meamLeak.cpp
lars@linux:~/test> MALLOC_TRACE=mlog memLeak
lars@linux:~/test> mtrace memLeak mlog

Memory not freed:
-----------------
Address Size Caller
0x0804a388 0x280 at 0x400d90ee
lars@linux:~/test>
----------
File memLeak.cpp is attached.
Apparently causing the problem is code line 15, where an empty string
is appended to the basic_string<char> test. I have tried test->clear()
to unallocate the memory used, but it didn't change the result (memory
leak still occurs). I have no idea how to unallocate the memory. Any
input?

Regards,
Lars

File memLeak.cpp:
-----------------------
#include <mcheck.h>
#include <string>

using namespace std;

typedef basic_string<char> myString;

int main( int argc, char ** argv )
{
mtrace();

myString *test;

test = new myString;
test->append("");
delete test;

return 0;
}

 

[lars.uffmann]

Hmm - this seems to be the bug I discovered:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128467

Comment 2 says:
"This is a known issue with the default allocator in gcc-3.[23].x.
These limitations have been removed for 3.4.x series."

Does that mean I need to upgrade to gcc 3.4.x if I don't want to use
the workaround?

Regards,

Lars

 

[lars.uffmann]

Does that mean I need to upgrade to gcc 3.4.x if I don't want to use
the workaround?

I should really read ALL comments before posting here *g*
Comment #3 on bugzilla says "Fixed for gcc 3.4."

Seems case is closed... Thanks for listening to me talking to myself
*g*

Regards,

Lars

 

[Kai-Uwe Bux]

I just reduced a nasty and hard to pin-down memory leak (according to
mtrace() under SuSE 9.3 to a very simple example file and would like to
know what the error is about, and whether it maybe is a bug in the
basic_string-template, or a bug / problem with mtrace, or something
else - and if other people can reproduce it - possibly under
non-SuSE-distributions.

Using g++ to compile memLeak.cpp with gnu c compiler 3.3.5, the
following happens:
-----------
lars@linux:~/test> g++ -o memLeak meamLeak.cpp
lars@linux:~/test> MALLOC_TRACE=mlog memLeak
lars@linux:~/test> mtrace memLeak mlog

Memory not freed:
-----------------
Address Size Caller
0x0804a388 0x280 at 0x400d90ee
lars@linux:~/test>
----------
File memLeak.cpp is attached.
Apparently causing the problem is code line 15, where an empty string
is appended to the basic_string<char> test. I have tried test->clear()
to unallocate the memory used, but it didn't change the result (memory
leak still occurs). I have no idea how to unallocate the memory. Any
input?

Regards,
Lars

File memLeak.cpp:
-----------------------
#include <mcheck.h>
#include <string>

using namespace std;

typedef basic_string<char> myString;

int main( int argc, char ** argv )
{
mtrace();

myString *test;

test = new myString;
test->append("");
delete test;

return 0;
}

Try a loop:

#include <mcheck.h>
#include <string>

using namespace std;

typedef basic_string<char> myString;

int main( int argc, char ** argv )
{
mtrace();

myString *test;

for ( unsigned int i = 0; i < 100000000; ++i ) {
test = new myString;
test->append("");
delete test;
}
return 0;
}


Does the "leaking" compound? If not, your STL very likely uses a pooling
allocator. Those do not leak but can confuse some debugging tools.


Best

Kai-Uwe Bux

 

[Alex Buell]

I just reduced a nasty and hard to pin-down memory leak (according to
mtrace() under SuSE 9.3 to a very simple example file and would like
to know what the error is about, and whether it maybe is a bug in the
basic_string-template, or a bug / problem with mtrace, or something
else - and if other people can reproduce it - possibly under
non-SuSE-distributions.

Don't use mtrace() anymore. There's an excellent tool called valgrind
which works much better, and does not require you to do anything
special in your code.

I have just run valgrind on memleak.cpp and it reports no problems with
your code at all. If I comment out the line containing 'delete test',
it does report a leak.