By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,649 Members | 1,816 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,649 IT Pros & Developers. It's quick & easy.

memory leak with deque ?

P: n/a

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.

Jul 6 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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.
Jul 6 '06 #2

P: n/a
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

Jul 6 '06 #3

P: n/a
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
Jul 6 '06 #4

P: n/a
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
Jul 6 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.