Thread: Memory leak

  1. #16
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by ssharish2005 View Post
    @g4j31a5
    @Yarin
    The answer is wrong. I mentioned not using any memory management tools. No tools should be used.
    Sorry, I misunderstood "memory management tool" to mean something that manipulates your program's memory, not monitor it.

  2. #17
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by brewbuck View Post
    malloc() isn't guaranteed to be thread-safe, but most modern C runtimes provide a thread-safe malloc() which is much more efficient than simply wrapping all calls to malloc() with a big lock.
    Chances are he'd be doing more that counting malloc()s and free()s, so locking would probably be wisest anyway. But really, it's not that big of a deal, wrapping the wrapper in a mutex would be _very_ easy, and not that bad on performance - at least, better than a big lock, I think.

  3. #18
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by brewbuck View Post
    malloc() isn't guaranteed to be thread-safe, but most modern C runtimes provide a thread-safe malloc() which is much more efficient than simply wrapping all calls to malloc() with a big lock.
    Well, not doing it would end us up with, it works sometimes, but not guaranteed. Not exactly what a programmer wants to hear. Unless the extra performance bump is really needed, I'd say guarantee before performance. Saves some headache.
    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.

  4. #19
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,732
    Quote Originally Posted by vinothkumar View Post
    Hi
    Code:
     void *debug_malloc(size_t bytes)
    {
       allocs++;
       return malloc(bytes);
    }
    In this code you are trying to increment the alloc value before allocating the actual memory for the pointer which gives wrong statistics when you analyse the debug prints finaly.same for free API also
    I do agree that we could have checked the returned value of malloc before incrementing the alloc. Which would go along with your statistics. Although i guess, I just looking for vague how people can think on it.

    Although the malloc isn't thread safe, I would say having wrapper function, counter in the function to keep count on the allocations and deallocation and mutex to be sync with the multi thread would rather be the solution for all. Well there we go; all this i should thought in 30 sec time. Which I missed out, and a big loss in not getting into a big company.

    ssharish
    Life is like riding a bicycle. To keep your balance you must keep moving - Einstein

  5. #20
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    Quote Originally Posted by ssharish2005 View Post
    @g4j31a5
    @Yarin
    The answer is wrong. I mentioned not using any memory management tools. No tools should be used.

    And other yes you guys are right. It’s as simple as printing out a debug statement and keep track of how much you allocate and deallocate. This is what employers are looking for. They are looking for a very simple answer and I couldn't think in a way different as put in some debug print. I was thinking ah how could the debug print might be helpful. And I said we might have to step through the code in that case. This is of course a time consuming task. What at the end, I just said "I’m not sure how debug prints, will help". And he went *surprised* YES IT WOULD!!! Why not*. And it all made sense. Perhaps I was thinking in the same context, but my mind wasn't working on giving him a simple solution. But it turned out to be that he was expecting just about that simple answer (debug prints)

    ssharish

    Well, actually if you used Visual Leak Detector, it has done all the wrappings for you because it is not actually a tool per se. It is not a separate application, but rather a library which will wrap the new and delete to its own implementation with an added memory leak detection. Because it's open source, you can actually look into the code to get an idea for your own custom leak detection if you want. But then again, you can use it as it is beause IMHO it's pretty good.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  6. #21
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    Quote Originally Posted by g4j31a5 View Post
    Well, actually if you used Visual Leak Detector, it has done all the wrappings for you because it is not actually a tool per se. It is not a separate application, but rather a library which will wrap the new and delete to its own implementation with an added memory leak detection. Because it's open source, you can actually look into the code to get an idea for your own custom leak detection if you want. But then again, you can use it as it is beause IMHO it's pretty good.
    I believe that's the same thing as what valgrind does.

  7. #22
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    Quote Originally Posted by cyberfish View Post
    I believe that's the same thing as what valgrind does.
    Yeah it is. However what I was suggesting was maybe he can look into it so that he can maybe get an inspiration about how to do it himself. Visual Leak Detector is also pretty verbose and complete in its reporting. It shows the dumping stack, the line of code which is leaked, etc. And it can be easily activated / deactivated by including a single header file and defining "USE_VLD" in any code he wishes to check for leak (and undefining it in any other code). Then again, I don't know if ssharish2005 is using Visual C or not because VLD is using CRT debug heap to check for leaks. But it's still worth a shot to look IMHO.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  8. #23
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,732
    Quote Originally Posted by g4j31a5 View Post
    Yeah it is. However what I was suggesting was maybe he can look into it so that he can maybe get an inspiration about how to do it himself. Visual Leak Detector is also pretty verbose and complete in its reporting. It shows the dumping stack, the line of code which is leaked, etc. And it can be easily activated / deactivated by including a single header file and defining "USE_VLD" in any code he wishes to check for leak (and undefining it in any other code). Then again, I don't know if ssharish2005 is using Visual C or not because VLD is using CRT debug heap to check for leaks. But it's still worth a shot to look IMHO.

    I have used all the tools which you guys mentioned. Valgrind is something common which I use on unix platform. The interesting bit is to how would you find memory leak with no such tool in use and quite easily. The easy solution as everyone else is ti have wrapper function and counter and how much you allocate and deallocate. You know, you don’t have the conformability of such memory management tools when your working on embedded system. For example: developing wireless protocol stack for a mobile device and many other applications. Things can get very tricky and challenging to find memory leaks in such an environment.

    ssharish
    Life is like riding a bicycle. To keep your balance you must keep moving - Einstein

  9. #24
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Without a tool, the way to find memory leaks is static analysis by hand: identify the conditions in which memory is allocated, the conditions in which memory is deallocated, and determine if every allocation is eventually matched with exactly one deallocation. A leak is any allocation that is not matched by any deallocation. Other conditions include an unwanted deallocation (deallocating something that was never allocated), or multiple deallocation (memory allocated but deallocated more than once).

    The disadvantage of static analysis is that it is not easy to perform - in fact, it takes a lot of effort, particularly with code that has complex logic (branching, etc). It has advantages though (if one manages to perform the analysis correctly and completely). Firstly, it is predictive, so it is not even necessary to run the program. Second, it is guaranteed to identify all memory allocation/deallocation errors - whereas valgrind cannot find concerns in code that has not been executed (which means, if you are to use valgrind properly, you actually need some form of coverage analysis to ensure all possible scenarios with memory allocation errors are executed). Third, the technique is applicable to any system resource that a program might use (memory, file handles, mutexes, etc).

    There are static analysis tools available, but producing such tools is also difficult. Most of the inexpensive static analysis tools are incomplete (i.e. there are things they miss) and the better quality tools are quite expensive.

    The best practical technique, however, for handling memory allocation errors is prevention: design and code in a manner that ensures memory leaks (and other memory-related errors) cannot occur. But few programmers have the necessary discipline, and too many programmers believe that hacking (throwing code together until it looks like it works) is a viable engineering method ......
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  10. #25
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by grumpy View Post
    Without a tool, the way to find memory leaks is static analysis by hand:
    The idea in post #4 won't "find" where a leak occurs, but it would "find" a leak if one exists without manual analysis or an external tool.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  11. #26
    Registered User
    Join Date
    Jun 2011
    Posts
    6
    Hi Harish..
    All your posts are quite interseting..I just wanted to discuss more things to you...I am not able to find any chat options in the message board..also i am new to this board and i don't have sufficient priviliages to see others profile or e-mail id...

  12. #27
    Registered User
    Join Date
    Jun 2011
    Posts
    6
    Hi Harish..

    In wireless protocol stack development generally they won't use this dynamic memory allocation procedure.They allocate the memory initialy as a whole contigous block and they will be having their own memory manangement API's to manage the memory allocation and de-allocation within that contigous blocks which allocated initialy.Also they will be having there own memory management procedures which is developed by them.So in that case you can't use those tools which is platform specific and the only way is to put some debug prints in the code if you want to know how much memory is allocated and how much memory is de-allocated.

    Are you attending any interviews?Are you looking for any sodtware protocol stack development jobs?
    Could you send me your gmail id?

  13. #28
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,732
    Quote Originally Posted by vinothkumar View Post
    Hi Harish..

    In wireless protocol stack development generally they won't use this dynamic memory allocation procedure.They allocate the memory initialy as a whole contigous block and they will be having their own memory manangement API's to manage the memory allocation and de-allocation within that contigous blocks which allocated initialy.Also they will be having there own memory management procedures which is developed by them.So in that case you can't use those tools which is platform specific and the only way is to put some debug prints in the code if you want to know how much memory is allocated and how much memory is de-allocated.

    Are you attending any interviews?Are you looking for any sodtware protocol stack development jobs?
    Could you send me your gmail id?
    Yes I know the technique which you’re talking about, memory pool management. This quite often used in almost all major embedded product development. But although its design independent, if the vendor has their proprietary OS things can be very different. Yes you’re right, in saying that we don’t have the comfort ability in using all the tools while working on the embedded systems, as its all platform independent.

    ssharish
    Life is like riding a bicycle. To keep your balance you must keep moving - Einstein

  14. #29
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by MK27 View Post
    The idea in post #4 won't "find" where a leak occurs, but it would "find" a leak if one exists without manual analysis or an external tool.
    Not true. That idea may identify presence of leaks. Unless it is somehow established that all possible program paths are exercised - and doing that is quite difficult, and often prohibitive, in practice - then the technique does not guarantee to identify all memory leaks.

    Testing can only definitely prove the presence of a bug (if it stumbles over one). Testing cannot, however, prove the absence of a bug, unless it is possible to prove that all possible program paths are executed during the test.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  15. #30
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by grumpy View Post
    Testing can only definitely prove the presence of a bug (if it stumbles over one). Testing cannot, however, prove the absence of a bug, unless it is possible to prove that all possible program paths are executed during the test.
    That's only true WRT "any kind of bug" -- no amount of testing can demonstrate there are no possible bugs of any sort. However, testing can demonstrate that no bug of a particular sort exists, such as a memory leak. At exit, valgrind will give you an allocated/free summary and say "All heap blocks were freed -- no leaks are possible", by which I do not think they mean "nothing is true, everything is permitted", or "there may be leaks, just we did not find any involving your computer's memory", etc.

    There may be plenty of cases where that method won't work, and I've never used it myself, but I think there are plenty of cases where, logically, it will work perfectly.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 09-28-2006, 01:06 PM
  2. Memory Leak Help
    By (TNT) in forum Windows Programming
    Replies: 3
    Last Post: 06-19-2006, 11:22 AM
  3. Do I have a memory leak? (SDL)
    By antex in forum Game Programming
    Replies: 3
    Last Post: 03-02-2006, 06:18 PM
  4. Is this a memory leak?
    By jasonhv in forum C++ Programming
    Replies: 5
    Last Post: 10-20-2005, 08:37 PM
  5. A memory leak (I think...)
    By Stevek in forum C++ Programming
    Replies: 7
    Last Post: 03-16-2003, 03:09 PM