What's the easiest way to output how much memory my program is leaking? (Total allocations / deallocations) (Also, I'm just using new/delete, not malloc/free)
I am mainly using unix (gdb/g++) if that makes it easier. Or I can also copy my code files into MS Visual C++ on WinXP if there's a better way there?
Last edited by Paul22000; 07-07-2008 at 10:44 PM.
Use valgrind if you're on Unix/Linux.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Ahhh! Thanks!Originally Posted by Salem
Now I'm running my program like this: valgrind --leak-check=full ./proj < inp1
This gives me:
Is there a way to get more information about a certain leak?Code:==31508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1) ==31508== malloc/free: in use at exit: 1,602 bytes in 108 blocks. ==31508== malloc/free: 232 allocs, 124 frees, 3,361 bytes allocated. ==31508== For counts of detected errors, rerun with: -v ==31508== searching for pointers to 108 not-freed blocks. ==31508== checked 121,928 bytes. ==31508== ==31508== 116 (64 direct, 52 indirect) bytes in 4 blocks are definitely lost in loss record 7 of 12 ==31508== at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163) ==31508== by 0x804A5A4: SCLLRep::Insert(Element*) (SCLL.cpp:57) ==31508== by 0x8048E51: main (proj.cpp:72) ==31508== ==31508== ==31508== 398 bytes in 27 blocks are possibly lost in loss record 12 of 12 ==31508== at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163) ==31508== by 0x34071FA: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.8) ==31508== by 0x3407D97: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in /usr/lib/libstdc++.so.6.0.8) ==31508== by 0x3408947: std::string::reserve(unsigned) (in /usr/lib/libstdc++.so.6.0.8) ==31508== by 0x33DF2E9: std::basic_istream<char, std::char_traits<char> >& std::operator>><char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (in /usr/lib/libstdc++.so.6.0.8) ==31508== by 0x8048E96: main (proj.cpp:77) ==31508== ==31508== LEAK SUMMARY: ==31508== definitely lost: 64 bytes in 4 blocks. ==31508== indirectly lost: 52 bytes in 4 blocks. ==31508== possibly lost: 398 bytes in 27 blocks. ==31508== still reachable: 1,088 bytes in 73 blocks. ==31508== suppressed: 0 bytes in 0 blocks. ==31508== Reachable blocks (those to which a pointer was found) are not shown. ==31508== To see them, rerun with: --show-reachable=yes
For example, none of the bolded leaks above have file or line numbers. Can I get more detailed about these specific leaks?
The line numbers that matter are really the ones in YOUR code - what is on line 77 of your proj.cpp? I don't believe the C++ library is leaking on simple string operations, which means that it's likely that you do something like this:
and never do the corresponding:Code:std::string *s = new string(10); ...
--Code:delete s;
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
That's the odd thing.
I have:And line 77 is:Code:string oper, r, x;The cin line appears elsewhere in main as well, and the fact that it doesn't yell at me on those for the same reason is the odd thing...Code:cin >> r >> x;
Noob question: ALL memory deallocation in C++ is just with the "delete" keyword, correct? Don't need to do anything else?
(From C, we learned about "free" in class but never used it in any assignments.)
It does make me think that it's a "false positive".
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Best way is to use smart pointers to avoid leaks in the first place, though.
(See boost::shared_ptr or std::tr1::shared_ptr)
delete for single allocation and delete [] for block allocation.
ie...
If you do not use the [] version where you should, you potentially leak memory.Code:int *x = new int; delete x; int *y = new int[100]; delete []y;
Not quite (e.g., as you pointed out the memory management functions from C are available in C++), but generally you would use delete to match new and delete[] to match new[].But yes, in C++, it's all just "delete", correct?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Is SCLLRep your class? Does it have an Insert function that takes an Element*? I would look at that as the possible cause.
Yes it does.
Main creates a *pointer, and then inserts it into a list.
Is that copy by value? So delete the pointer after inserting?
Code:string x; cin >> x; Element* pointerToElement = new Element(x); Set* pointerToSet = ... ... pointerToSet->Insert(pointerToElement); // Delete pointerToElement?
Last edited by Paul22000; 07-08-2008 at 05:23 PM.
Since we're adding things, I'd add that in modern C++, the use of smart pointers often means that the delete is hidden (in many cases the new is hidden as well, but not all of them). So it is entirely possible to use new but not call delete directly because you use a smart pointer to handle that for you.
>> Thanks for the info on delete [] everyone!
Note that you should almost never be using delete[] in an actual C++ program, because there are few reasons to use a dynamically allocated array. If you think you need new[] and delete[], use vector instead.
It depends on what the Insert function does. Normally, you don't want to delete the pointer after calling insert, but if the set is storing objects and not pointers, then maybe you do.
Do you have the code or the documentation on what Insert is doing exactly?
If the Set owns the objects it holds (i.e. it is storing objects or allocating its own pointers), I wouldn't even be using new in the first place to create the Element, I'd create a local variable.
