Sandy Ganz wrote:
This doesn't sound right, I have seen the problem that linux will not use the allocated memory until it is touched, but doesn't the memory manger keep track ultimatly of all allocations (in the kernel which as all encompassing knowledge of allocations) which might include things that have not yet been written too? In some of the apps that I wrote I saw the behaviour that I
This is intentional. It has all the information it needs, but it doesn't want to fail, since the apps allocating the memory may not need it all simultaneously. As I recall, FreeBSD behaves the same way.
could not allocate more ram and malloc fails, but never really noticed if it fails on memory that has not been touched. I do remember in TOP not seeing allocations happen until it was cleared (memset). For the critical stuff I preallocate and mlock() allocated memory to force it into ram for most of the server processes, but other processes, have run out of ram at allocation time, so I'm not sure that it won't fail just on allocation (all on linux 2.4x btw). Good food for thought...
Been a while since I last thought about this issue, but if I remember correctly, you get a malloc() failure if the OS is unable to allocate another page of memory for allocation overhead, and a success if it can allocate that but doesn't have enough swap space left to write to all of it.
If you need to be sure that you detect out-of-memory conditions when allocating, you need to write to it immediately and catch any signals, OS exceptions, or whatever the target platform uses.
--
http://www.velocityvector.com/ | http://www.indie-games.com/
http://www.classic-games.com/ | http://glmiller.blogspot.com/
"If my forgeries looked as bad as the CBS documents, it would
have been 'Catch Me In Two Days'" -- Frank Abagnale, Jr.
