memory leak with deque ?

[mast2as]

Hi again

I was still debugging some code and check for memory leaks with
valgrind and found out that valgrind finds a leak when i use
deque<Somethingaqueue ?! I am compiling under Linux

for example:
#include <deque>
using namespace std;

int main()
{
deque<inttest;
test.clear();
return 0;
}

is there something I can do or I am doing something wrong ?

Thanks -

valgrind output
===========
==18232==
==18232== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from
1)
==18232== malloc/free: in use at exit: 1280 bytes in 1 blocks.
==18232== malloc/free: 3 allocs, 2 frees, 1796 bytes allocated.
==18232== For counts of detected errors, rerun with: -v
==18232== searching for pointers to 1 not-freed blocks.
==18232== checked 2370932 bytes.
==18232==
==18232== 1280 bytes in 1 blocks are still reachable in loss record 1
of 1
==18232== at 0x1B90406F: operator new(unsigned)
(vg_replace_malloc.c:133)
==18232== by 0x1B986B9A: std::__default_alloc_template<true,
0>::_S_chunk_alloc(unsigned, int&) (stl_alloc.h:108)
==18232== by 0x1B986AAC: std::__default_alloc_template<true,
0>::_S_refill(unsigned) (stl_alloc.h:550)
==18232== by 0x1B9867A7: std::__default_alloc_template<true,
0>::allocate(unsigned) (stl_alloc.h:357)
==18232==
==18232== LEAK SUMMARY:
==18232== definitely lost: 0 bytes in 0 blocks.
==18232== possibly lost: 0 bytes in 0 blocks.
==18232== still reachable: 1280 bytes in 1 blocks.
==18232== suppressed: 0 bytes in 0 blocks.

[Ian Collins]

ma*****@yahoo.com wrote:

Hi again

I was still debugging some code and check for memory leaks with
valgrind and found out that valgrind finds a leak when i use
deque<Somethingaqueue ?! I am compiling under Linux

for example:
#include <deque>
using namespace std;

Why?

int main()
{
deque<inttest;
test.clear();
return 0;
}

is there something I can do or I am doing something wrong ?

What happens if you put the test code in its own scope or function?

--
Ian Collins.

[joycemenger]

using namespace std;

Why?

Hi Ian

I am assuming you ask why i am using "using namespace std" ?. No reason
really just because i am using some test.cpp file to debug random code
and I have lines that sometimes i don't remove...

About your over question. Orginally in the code I am talking about,
deque is definitely declared in a class. When I comment that line out
valgrind doesn't report anything. So I did a test by calling deque
directly in the simplest possible main program and i get the same error
report. But I will do some tests again tomorrow when I am back at work
that I could send to that thread.

Also I was going to test the same code but by replacing deque (which I
recently started to use) with vector (which i used in my previous
apps).

Thanks -Mark

[Tom Widmer]

ma*****@yahoo.com wrote:

Hi again

I was still debugging some code and check for memory leaks with
valgrind and found out that valgrind finds a leak when i use
deque<Somethingaqueue ?! I am compiling under Linux

for example:
#include <deque>
using namespace std;

int main()
{
deque<inttest;
test.clear();
return 0;
}

is there something I can do or I am doing something wrong ?

Obviously, your code and the library code are fine. Your interpretation
(or configuration) of valgrind is the problem.

>
Thanks -

valgrind output
===========
==18232== 1280 bytes in 1 blocks are still reachable in loss record 1
of 1
==18232== at 0x1B90406F: operator new(unsigned)
(vg_replace_malloc.c:133)
==18232== by 0x1B986B9A: std::__default_alloc_template<true,
0>::_S_chunk_alloc(unsigned, int&) (stl_alloc.h:108)

That looks like a false memory leak report by valgrind. Note it mentions
that the memory is still "reachable". All that is happening is that the
library implementation is using a caching allocator, that holds onto
memory that is freed so that it can reuse it later.

You should be able to switch this caching behaviour off, just for the
purposes of memory leak detection. Have a look at your library
documentation under allocators to see how to disable it. e.g.
http://gcc.gnu.org/onlinedocs/libstd...allocator.html

Tom

[mast2as]

Thanks a lot Tom

This is the first time I am really trying to write a serious program
here and I must say that the other person I am developing this project
with and I are learning a lot of stuff on C++. Can't say it is always
fascinating but it certainly shows that I know little about the subject
;-)

I was expecting the library to indeed do something like that but didn't
know how to put a name on it. Now that you explained it to me, I will
look into it.

Thanks again, mark
Tom Widmer wrote:

That looks like a false memory leak report by valgrind. Note it mentions
that the memory is still "reachable". All that is happening is that the
library implementation is using a caching allocator, that holds onto
memory that is freed so that it can reuse it later.

You should be able to switch this caching behaviour off, just for the
purposes of memory leak detection. Have a look at your library
documentation under allocators to see how to disable it. e.g.
http://gcc.gnu.org/onlinedocs/libstd...allocator.html

Tom