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