Did you start two threads for this same question? Or did you change your user ID and start three threads for the one question:
http://www.linuxquestions.org/questi...-leaks-803024/
http://www.linuxquestions.org/questi...-space-803426/
Having part of the details we need to give a specific answer in each of three threads makes it much more difficult to provide an answer.
Quote:
Originally Posted by chamara82
I have checked my program for memory leaks and found None(Valgrind,purify).
|
That isn't a strong reason to believe there are no memory leaks. Valgrind and purify are not very accurate. There are many kinds of leaks they can't report.
Quote:
times i execute the same tasks
|
That phrase needs a lot more clarification. In context of the thread, it would seem you mean the program is running continuously and the program does some operation which malloc's a bunch of memory and the frees
all of it before the next time. If that were true, you would not see the growth in VIRT that you claim. So probably you do have a memory leak.
But that estimate is extrapolating a lot from your unclear statements.
Quote:
Originally Posted by chamara82
But the growth is degrading over the number of times of the execution of the tasks. Can i think that fragmentation plays a role in this?
|
Consider a program that has a lot of small allocations and never frees a large fraction of them at once. Instead it might replace them one at a time with similar, but not exactly the same size, allocations.
When malloc allocates a chunk, it might not have a free one of exactly the right size nor have a big contiguous free area, so it might split a slightly larger chunk into the chunk needed and a small fragment that won't get used. If you later need the size that it split, it might no longer be available, causing malloc to split a larger chunk again. Soon malloc would need to get more from the OS even though the total of all allocations might not be changing much.
So in that rolling replace mode (unlike the deleting it all at the end of each task and reallocating for the next task) the average amount wasted for allocations might gradually go up as the rolling replace varies the chunk sizes.
But the fragments aren't lost forever. They come back when you free the adjacent chunks. So as you continue such a rolling replace, the amount that the average freed size exceeds the actual use should soon catch up with the amount the average allocation cost exceeds the actual use.
All of that assumes a rolling replace design with random small size variations. That is an even wilder extrapolation from the little info you have provided.