Quote Originally Posted by nuzzle View Post
The programmer is right, a process may not give back memory to the OS but this isn't an excuse for not fixing the problem. If the memory increase is unrelated to an increase in workload it usually is a memory leak.
If this is true, then there may not actually be a memory leak. There is definitely high levels of workload on occasaions. Data comes in in spurts... there'll be nothing for periods of time, then suddenly large amounts of data are received. It's during those lull periods that we do not see a release of memory from one particular process. So, again, if you're correct, in that a process may possibly not return memory to the OS, then that would explain why we see no decrease in memory. However, we do see decreases in other processes. As I mentioned, one of the tools used to monitor memory usage is "top". Is this not a valid way to assess this possible problem?

Quote Originally Posted by nuzzle View Post
Usually the memory footprint of a process will never shrink, only expand. It depends on the runtime system of the programming language technology you're using. When a programmer releases heap memory it's to the runtime system. It's then up to the runtime system whether to pass memory on to the OS.
The process in question is written in C++ using a GNU compiler (version 4.1.2). It runs on a Redhat linux OS (version 5.4). I have no idea how this runtime system works, or even how to find out. However, if memory is not being released back to the OS, then why would we see memory reductions (again, using "top") with other processes?