06-24-2011
4,673,
588
Join Date: Oct 2010
Last Activity: 1 February 2016, 3:35 PM EST
Location: Southern NJ, USA (Nord)
Posts: 4,673
Thanks Given: 8
Thanked 588 Times in 561 Posts
Well, leaks mean that programs use an increasing amount of swap, show a larger vm size on ps and may eventually bomb. Every malloc()/calloc()/realloc()/new must be to a pointer not overwritten or out of scope before a corresponding free()/delete, except if you exit(). If a subroutine returns a new object or dynamically allocated space, the caller may inherit the obligation to delete or free() when out of use, if not exit(). You may be calling other people's libraries that put this obligation on you.
Declaring excess or VM intensive choices is a more subtle, architectural problem.
The mmap()/mmap64() facilities are unique, allowing you to map files (or swap or copy to swap on write) creating memory spaces you can just reference for accessing values or to write (persistent) variable values, no read or write, just =, memcpy() and such. If you write a file and mmap() the file, not malloc and fill an array, you are still using as much RAM, and address space, but no swap space to provide rollout space for the array (sometimes, swap allocation is delayed until first rollout). If you run out of address space, you can munmap() some old space and mmap() a new chunk, so you have infinite VM (and potential RAM use) in just a 32 bit app. You can even do huge sparse arrays with seek, write -- ufs will not allocate blocks for null spaces never written, and mmap64() the whole sparse array. I wrote a fgrep that used open(), mmap(), string search, munmap(), close(). When testing, I did a search of every file, and rolled every app on the system out as I paged in files totaling more than the system RAM size, temporarily freezing every other application and user. Even after you close and munmap(), the file is available in RAM for the next mmap(), until it ages out. This is great for /lib/libc.so or moving your windows into files around, but not so great for private files in huge numbers.
What, exactly, is your concern?
Last edited by DGPickett; 06-24-2011 at 11:32 AM..