Thread: Memory leak prevention methodogies

  1. #1
    Registered User
    Join Date
    Nov 2007
    Posts
    3

    Memory leak prevention methodogies

    Hi all,
    I’m studying a problem releated to memory leakage.
    Now, there are many tools to check memory leakake at run-time (dynamic analysis), and some tools can check memory leakage at compile-time (static analysis). But I have some questions:
    How do you think to prevent memory leakage from coding phase (without using tool)? (or In coding phase, what do you have to do to prevent memory leakage?)
    I want to investigate from many programmers in many countries.
    Can you help me?

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Use memory managers or shared pointers, such as boost's shared_ptr, define responsibility for who should clean up the memory and make common exit sections in functions so that everything is cleaned up and set your pointers to NULL when not needing them anymore.
    That's what I can think of.
    This is coding phase, of course.
    Last edited by Elysia; 11-12-2007 at 03:35 AM.

  3. #3
    Registered User
    Join Date
    Nov 2007
    Posts
    3
    Thanks!
    I'm searching information on internet and I found 2 solutions:
    - Using coding check list (or coding guide line)
    - Using template library to reduce memory leakage (for ex: vector, list, queue, auto_ptr...)
    and I need more information than that ...

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Well, for any larger program, it's almost impossible to investigate all paths that MAY be taken for a given program - so whilst static analyzis can spot OBVIOUS mistakes, e.g. there is an allocation, but no pointer is kept after the function exits:
    Code:
    void somefunc(char *s)
    {
       char *p;
        
       p = malloc(strlen(s)+1);
       strcpy(p, s);
       .... modify and mess about with p
       .... no call to free. 
    }
    But if this function were to return the value of p to the calling code, you'd have to follow the calling code to find out if p is maintained - after several branches, loops and conditionals, there may well be a situation where it can't be made certain that the code is correct or not.

    Dynamic analyzis is easier to implement - just track allocations and when the application exits, if there's any unfreed objects, those are memory leaks!

    --
    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
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Use RAII religiously. Don't allocate any resource that isn't released by a destructor.

    Once you really do that, the only remaining problem comes from owner cycles. To avoid these, do as Elysia said and define clear ownership rules for your objects.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by c___newbie View Post
    Thanks!
    I'm searching information on internet and I found 2 solutions:
    - Using coding check list (or coding guide line)
    - Using template library to reduce memory leakage (for ex: vector, list, queue, auto_ptr...)
    and I need more information than that ...
    Yes, you should use thoroughly tested objects rather than making your own to avoid memory leaks. Using vectors instead of arrays is a good thing to make sure you don't get leaks.
    There are, of course, coding guidelines to follow (like classes are in charge of their own memory - they do not give out pointers willingly to memory allocated by themselves and they should NEVER allow any outside function to delete its memory [in such case, a member function can be used to delete that memory]).

    Another good idea to avoid allocating on the heap, if possible. Pass by reference or by value, if it can be done.
    Take care to note the lifetime of your objects. Should they last the entire life of the app? Then free them when the app exits. If not, then free it after you're done with it.
    If a function allocates memory that another part of the code requires, a good guidelines is that the function that now allocated the memory will give up ownership to the other part of the code that gets the memory and hence THAT part will be responsible for cleanup.
    In general, it's also a good idea that a function that allocates the memory also frees it.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    In general, it's also a good idea that a function that allocates the memory also frees it.
    I think there's room for misunderstanding here.

    It is preferable that any function that allocates memory also frees it before it returns. However, sometimes memory (or any other resource) must outlive the function call. Don't misunderstand the above statement to mean that you should one function both for allocating and freeing a resource.

    (By the way, Elysia, I'm surprised. Have we converted you?)
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #8
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by CornedBee View Post
    I think there's room for misunderstanding here.

    It is preferable that any function that allocates memory also frees it before it returns. However, sometimes memory (or any other resource) must outlive the function call. Don't misunderstand the above statement to mean that you should one function both for allocating and freeing a resource.
    Of course, that's what I mean. If the memory is to be freed, let it (if possible) be the function that allocated it. If it must outlive the function, consider setting rules for how. Is it a function that creates an object and returns it? Then the function that takes it might free it, for example.

    (By the way, Elysia, I'm surprised. Have we converted you?)
    I watch and learn

  9. #9
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Use some software model checking techniques (formal methods).

  10. #10
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    ...Another good idea to avoid allocating on the heap, if possible...
    Proper cleanup of pointers is not what I would consider part of a design decision whether or not to use objects on the heap. C++ Programmers should know how to clean up heap objects.
    Design is what necessitates the use of the heap or lack of the use of the heap. So don't take that statement as you should always opt for or gravitate towards using non-heap objects. If you follow much of the advice given in this thread then you won't have any trouble managing memory.

    I find that in managed 'safe' languages like C# the lack of control given to me over my objects and their lifetime is quite an insult and normally flies in the face of what I want to do rather than assist me.

    One convention I've accustomed myself adhering to in unmanaged C++ is:

    m_pPointerToObject
    This is a pointer and it's owned by the class. So when you see:
    delete m_pPointerToObject in your code you know you are deleting an owned pointer.

    m_psPointerToObject
    This is a pointer but it's not owned by the class. When you see delete m_psPointerToObject you know something is amiss since you are deleting a shared pointer.

    Any convention is only as good as the programmer using it and this one is not idiot proof by any means. But if you follow this convention it should be easier to spot places where you are attempting to delete a pointer that someone else may still be using or need. Likewise a function that returns a shared pointer may also use a similar convention so that you know it is returning a shared pointer.

    Likewise the crtdbg library has tons of memory debugging features that will help you and the MSVC Debugger is quite good. Functions in crtdbg will tell you everything you want to know and a whole lot of stuff you didn't want to know about the memory.
    Last edited by VirtualAce; 11-12-2007 at 06:47 PM.

  11. #11
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by c___newbie View Post
    I want to investigate from many programmers in many countries.
    Can you help me?
    An approach nobody has mentioned yet:

    Don't use new/delete. You can't leak what you haven't allocated.

    EDIT: Okay, it has been mentioned.
    Last edited by brewbuck; 11-12-2007 at 09:26 PM.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Bubba View Post
    Proper cleanup of pointers is not what I would consider part of a design decision whether or not to use objects on the heap. C++ Programmers should know how to clean up heap objects.
    Design is what necessitates the use of the heap or lack of the use of the heap. So don't take that statement as you should always opt for or gravitate towards using non-heap objects. If you follow much of the advice given in this thread then you won't have any trouble managing memory.
    Of course you should use heap objects when you need them, but the general idea is to avoid them IF you don't need them. What you don't create, you don't need to free.

    Quote Originally Posted by Bubba View Post
    m_pPointerToObject
    This is a pointer and it's owned by the class. So when you see:
    delete m_pPointerToObject in your code you know you are deleting an owned pointer.

    m_psPointerToObject
    This is a pointer but it's not owned by the class. When you see delete m_psPointerToObject you know something is amiss since you are deleting a shared pointer.
    Wow. Good advice. I'll put that to mind.

  13. #13
    Registered User
    Join Date
    Nov 2007
    Posts
    3
    Ok, thanks for all comments, ideas, and experiences.
    This is very useful when apply them in coding phase.

  14. #14
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Of course you should use heap objects when you need them, but the general idea is to avoid them IF you don't need them. What you don't create, you don't need to free.
    Sorry but that is not my methodology or line of thinking about the design of my code. I know how to properly use memory and understand intimately the lifetime of my objects. Therefore whether I use heap objects or stack objects is purely a moot point. Every C++ programmer should understand how to use the heap. If you understand the heap and understand how to properly use it, I see no issues.

    I do not follow a general rule of AVOID heap objects. Everything is a tool and I just use the right tool at the right time for the right task.

  15. #15
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Bubba View Post
    Of course you should use heap objects when you need them, but the general idea is to avoid them IF you don't need them. What you don't create, you don't need to free.
    Sorry but that is not my methodology or line of thinking about the design of my code. I know how to properly use memory and understand intimately the lifetime of my objects. Therefore whether I use heap objects or stack objects is purely a moot point. Every C++ programmer should understand how to use the heap. If you understand the heap and understand how to properly use it, I see no issues.
    Reading what you quoted, it says: "Use the heap when you need it. Don't use the heap when you don't need it." You say you disagree. Which part of that statement do you disagree with? The part about using the heap when you need it? Or the part about not using it when you don't?

    So, you seem to be making at least one, possibly both, of these two statements:

    1. You use the heap in cases where it is inappropriate.
    2. You do not use the heap in cases where it is the only way to do things.

    Which one of these statements are you making, if any?

    By using new/delete in cases where the goal could easily be accomplished another way, is to deliberately regress to a C-like worldview and all the difficulties that entails, and seems to miss the entire point of C++.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Memory leak in this case?
    By George2 in forum C++ Programming
    Replies: 3
    Last Post: 03-22-2008, 05:05 AM
  2. memory leak in the code?
    By George2 in forum C++ Programming
    Replies: 20
    Last Post: 01-13-2008, 06:50 AM
  3. Is this code memory leak free? ---> POSIX Threads
    By avalanche333 in forum C++ Programming
    Replies: 9
    Last Post: 04-13-2007, 03:19 PM
  4. Any Memory Leak Checking Tool?
    By George2 in forum C Programming
    Replies: 4
    Last Post: 06-21-2006, 11:02 PM
  5. Manipulating the Windows Clipboard
    By Johno in forum Windows Programming
    Replies: 2
    Last Post: 10-01-2002, 09:37 AM