Originally Posted by saleem_ak
Is this anything to do with the 32 bit application running on 64 bit OS.
I did do a valgrind analysis of the application and found no major leaks, the virtual memory is reaching 4GB, before my application is getting killed.
The fact that it can reach 4GB, rather than aborting at 3GB, is because you are running a 32bit application on a 64 bit OS. (There are also some 32bit Linux kernels that can let an application have a full 4GB, but it isn't typical).
It is very unlikely that the 64bit kernel is a factor either in some memory leak you haven't detected or in something like the malloc system failing to return memory to the OS after the application frees the memory. Malloc returning freed memory all the way back to the OS is a complicated issue. It certainly isn't a guaranteed behavior.
It is possible that a large chunk of the memory is unused demand zero memory: When the application asks malloc for a tiny amount of memory, malloc asks the OS for a much larger amount, then it parcels out that large allocation to subsequent application requests for small amounts. If the application continues to want more, malloc will ask for an even bigger chunk from the OS each time the last chunk runs out. Pretty soon it will ask for the biggest chunk the OS can give. In a 32bit app in a 32bit OS that may bring the total to nearly 3GB, while the same 32bit app at the same moment in a 64bit OS may jump to nearly 4GB. If that happens to be nearly the end of the app's increase in memory use, the VIRT size of the app will show that 3GB or 4GB value even though the memory isn't really being used (the allocation takes neither physical ram nor swap space).