11–15 of 15 posts
From the malloc man page (under BUGS):
"By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available."
It goes on to describe how this behavior can be turned off.
Similar policy is used in Linux for disk space: 10% of disk space is reserved for root.
PS. Linux OOMKiller already do something similar: it just kills a process to free some memory.
The "segfault policy" is an extremely bad idea. Over the past couple years, several major security vulnerabilities have been caused by programs that took the "segfault" path making attacker-controlled array references to NULL pointers. It's not hard to see that if you index something with a standard native integer, 0 + index can mean any word in memory. If you write to that, that's game over. It's for a similar reaso…
This seems like a good approach. Could you offer more details? I can do it with the MALLOC_CHECK_ environment variable in glibc, but is there some better way to do it at link time? In compiling my own code I can use a wrapper, but I'm not sure how to ensure that strdup aborts.
Allocate 1MB of memory upfront. When OOM happens, free that memory and run recovery mechanism. Similar policy is used in Linux for disk space: 10% of disk space is reserved for root. PS. Linux OOMKiller already do something similar: it just kills a process to free some memory.
No OOM recovery is fool proof. What if the OOM situation is caused by another process constantly consuming memory? As soon as you free your 1MB overhead, the other process could immediately consume it and again you're in an OOM state.
Granted, the likelyhood of this is slim, but then again, so is an OOM situation period. In the world of virtual memory and swap space, it pretty much takes a rogue process to trigger an OOM error in the first place.
Allocate 1MB of memory upfront. When OOM happens, free that memory and run recovery mechanism. Similar policy is used in Linux for disk space: 10% of disk space is reserved for root. PS. Linux OOMKiller already do something similar: it just kills a process to free some memory.
Allocate 1MB of memory upfront. When OOM happens, free that memory and run recovery mechanism. No OOM recovery is fool proof. What if the OOM situation is caused by another process constantly consuming memory? As soon as you free your 1MB overhead, the other process could immediately consume it and again you're in an OOM state. Granted, the likelyhood of this is slim, but then again, so is an OOM situation period. In…