Actually for a process to run it needs text, stack , heap and data segments. All these find a place in the physical memory.
Out of these 4 only heap does exist after the termination of the process that created it. I want to know the exact reason why this happens. Also why the other process need to access the heap of my process. If the other processes compete for the heap that my process has consumed then there wont be need of an IPC mechanism (like my process will put the information in the heap and give that address to the peer process to have the info shared) ...
My question is really simple, I am not freeing the text , data and stack segments used by my process, then y should i do it for heap alone? 
All of a process allocated memory should be made available after it dies otherwise the OS will refuse to launch after some period of time.
What OS are you using ?
How are you measuring the memory usage ?
I am using fedora 6
But y u say
"All of a process allocated memory should be made available after it dies otherwise the OS will refuse to launch after some period of time"
After a process dies y should its address space be avilable ? y OS wont launch when a process dies ?
I dont understand the point u try to make..
Please use English. It's quite boring for non native speaker (and probably for native ones) to decrypt non standard English.
Also, please answer the second question I asked.
After a process dies, all of its address space should be made available otherwise that would be a memory leak. Memory leaks always end in some crash or denial of service which is particularly unwanted for an operating system.
jlliagre didn't mean to say OS will not launch after a process has died, which translates OS won't launch once I issue a clear command.
The point that lies here is - if each and every process that have got poor memory allocation and deallocation within it, will start creating memory leaks ( try hitting memory leak in any SEs - good links will be provided ), slowly it will be using all of the available memory depriving any new process to be booted or loaded due to insufficient memory.
I understand that, But any part of the process's address space being leaked leads to a memory leak. But stack, data and text segments' memory is not at all leaked. Beacuse they are freed by the OS itself when a process terminates. But Heap alone needs to be freed explicitly. why is that so?
I use the "size"" command to find the size of each segment.
---------- Post updated at 07:23 PM ---------- Previous update was at 07:20 PM ----------
I understand your point matrix madhan. But can you expalin why the stack or data or text segment's memory is not leaked at all?
Other segments are allocated by OS, and OS knows to and does a good job of properly deallocating once the process is done. But memory to heap is explicitly allocated via - malloc ( are any memory allocation call ) which means that OS is giving authority to the caller to allocate memory which implicitly means its the onus of the caller to deallocate when not in use / not required.
With more power comes more responsibility 
This sounds very logical, But still the OS can know which part of Heap it has allocated to which process, then why cant the OS take care of freeing it when the process is getting killed. By the way,even if I call malloc to get memory, finally the OS does the allocation job, so it can still keep track of the meory allocated by the user. I tried reading memory leak stuff for quite sometime.. But couldnt find the answer why heap need to freed explicitly .. Please help me understand this
That doesn't make sense. A process shouldn't be required to free its heap memory or anything not specifically set as persistent when it dies.
Can you elaborate on how you use the size command to reach to your conclusions ? Especially what parameters do you pass to it. It doesn't seem to be usable for that purpose according to its manual page. Perhaps are you using a different "size" command ?
I am using the size command
sample output :
[root@cheuxsie82 cs]# size a.out
text data bss dec hex filename
1143 272 4 1419 58b a.out
I'm pretty sure the heap is freed when a process exits. In the end, it's just another segment. What malloc/free allows you to do is use, discard, and recycle bits of it frequently without having to keep track of all of it yourself. Its for convenience.
You mean to say that there wont be any problem at any point of time if there is memory leak in my code. right?
size a.out
is looking to a binary file on your disk that might have never run, or once, or multiple times and shouldn't be affected by it.
Does its output change while you run "a.out" several times ?
Of course, applications memory leaks disappear when the process dies.
No the output does not change at all. But many senior professionals in my office say that memleak is a serious issue. If you dont free it, it will cause fatal problems during execution. Can anyone tell me what memory leak would do to the process that caused it and other process running parallely?
Hopefully.
Sure, it can be. Is this statement general or based to issues you have with your application ?
It will eventually.
A memory leak will first slow down the system when no more RAM is available and the OS start paginating (swapping pages) intensively. After some time, the system might starve virtual memory too. What will happen will depend on what OS and kernel you use. Linux is known for its controversial OOM killer, a kernel task that blindly kill processes in order to free some memory.
memory leak problem should not be handled carelessly and should not be left to OS to handle that. It should be handled with care.
On your desktop or test host only ( not in prod ), write a program that only does malloc() without free() for every 30 seconds and see the system performance over period of time. Difference will be quite obvious.
Also, think of a ever running program like daemons and a memory leak problem in it, over a period of time, this memory leak problem will manifest itself and disturb the system.
No. Completely no. Heap memory is released when the process ends, whether or not the program called free(). The memory is released. After a process ends, the old process heap memory is no longer allocated to any process. Read man page for brk().
For long running programs and BEST PRACTICE in C coding, always call free().
I put this here as a correction. Not a comment.
Then I undertand that memory leak is meaningful as long as the process that caused it is alive. Once the process that caused it dies then all the leaked memory will made available to the OS memory manager. Am I right?
Correct. All memory - even leaked memory - that belongs to a process is reclaimed on process termination.
Considering the lifetime of a process, assuming that its short lived and its not ok to accept memory leaks in the code.
- Same thing might happen to a daemon - which will bring down system
- Trigger OOM errror
- A bug in short lived process (assuming its short lived) which eventually might be using up all the resources.
- Even for a short lived process, if the memory consumption is exponential, then we are done in much lesser time
So, the rule is - no memory leaks in the code and no memory leaks whatever be the life span of the process memory image 