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