Thread: How to Spot Memory Leaks?

  1. #1
    Registered User
    Join Date
    Apr 2008
    Posts
    167

    How to Spot Memory Leaks?

    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.

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,656
    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.

  3. #3
    Registered User
    Join Date
    Apr 2008
    Posts
    167
    Quote Originally Posted by Salem View Post
    Use valgrind if you're on Unix/Linux.
    Ahhh! Thanks!

    Now I'm running my program like this: valgrind --leak-check=full ./proj < inp1

    This gives me:

    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
    Is there a way to get more information about a certain leak?

    For example, none of the bolded leaks above have file or line numbers. Can I get more detailed about these specific leaks?

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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:
    Code:
    std::string *s = new string(10);
    ...
    and never do the corresponding:
    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.

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Best way is to use smart pointers to avoid leaks in the first place, though.
    (See boost::shared_ptr or std::tr1::shared_ptr)
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Registered User
    Join Date
    Apr 2008
    Posts
    167
    Quote Originally Posted by matsp View Post
    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:
    Code:
    std::string *s = new string(10);
    ...
    and never do the corresponding:
    Code:
    delete s;
    --
    Mats
    That's the odd thing.

    I have:
    Code:
    string oper, r, x;
    And line 77 is:
    Code:
    cin >> 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...

    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.)

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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.

  8. #8
    Registered User
    Join Date
    Apr 2008
    Posts
    167
    Quote Originally Posted by matsp View Post
    It does make me think that it's a "false positive".

    --
    Mats
    Ah ok cool. I'll try to patch some holes up when I'm done coding the project and see if it goes away!

    But yes, in C++, it's all just "delete", correct?

  9. #9
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    delete for single allocation and delete [] for block allocation.

    ie...

    Code:
    int *x = new int;
    delete x;
    
    int *y = new int[100];
    delete []y;
    If you do not use the [] version where you should, you potentially leak memory.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    You must make sure that you delete arrays with the array form of delete:
    Code:
    char *p = new char [10];
    ... 
    
    delete [] p;
    --
    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.

  11. #11
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,412
    But yes, in C++, it's all just "delete", correct?
    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[].
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #12
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    Is SCLLRep your class? Does it have an Insert function that takes an Element*? I would look at that as the possible cause.

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Paul22000 View Post
    But yes, in C++, it's all just "delete", correct?
    In summary:
    Allocations with new[] is matched with delete[].
    Allocations with new is matched with delete.
    Allocations with malloc is matched with free.

    New/delete is the C++ way, but the C way is also possible under C++.
    Malloc should never be paired with delete.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    Quote Originally Posted by Elysia View Post
    New/delete is the C++ way, but the C way is also possible under C++.
    Malloc should never be paired with delete.
    And to add to that, malloc() should not be used to ever allocate memory directly for an object of a type of class, since malloc() and free() do not handle the constructors and deconstructors of whatever type you are allocating. They just deal with raw memory.

    So to reiterate, new/delete is the way to go in C++.

  15. #15
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Checking for memory leaks
    By Bladactania in forum C Programming
    Replies: 5
    Last Post: 02-10-2009, 12:58 PM
  2. memory leaks
    By TehOne in forum C Programming
    Replies: 4
    Last Post: 10-10-2008, 09:33 PM
  3. Tons of memory leaks
    By VirtualAce in forum C++ Programming
    Replies: 11
    Last Post: 12-05-2005, 10:19 AM
  4. COM Memory Leaks
    By subdene in forum Windows Programming
    Replies: 0
    Last Post: 06-07-2004, 11:57 AM
  5. Memory leaks
    By Malek in forum C++ Programming
    Replies: 2
    Last Post: 02-09-2003, 06:12 PM