Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash
On Thu, May 06, 2004 at 09:05:29AM +0200, Vincent Lefevre wrote:
> In the 2.4 kernel documentation, Documentation/sysctl/vm.txt says:
>
> overcommit_memory:
>
> This value contains a flag that enables memory overcommitment.
> When this flag is 0, the kernel checks before each malloc()
> to see if there's enough memory left. If the flag is nonzero,
> the system pretends there's always enough memory.
>
> Isn't it clear?
>
> So, according to linux specification, the kernel does the check if
> overcommit_memory is 0 (my case)... unless the caller asks not to
> reserve (but malloc() is a reservation, so I don't see why glibc
> sets the MAP_NORESERVE flag, if I've understood correctly).
Overcommit does not work properly in 2.4, though. GOTO-san is right -
from your description you want strict overcommit, i.e. the value of 2
for this flag. Some of the 2.4-ac kernels had this. So does 2.6.
The description from 2.6 says:
The Linux kernel supports three overcommit handling modes
0 - Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slighly more memory in this mode. This is the
default.
1 - No overcommit handling. Appropriate for some scientific
applications.
2 - (NEW) strict overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is 50) of physical RAM.
Depending on the percentage you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
--
Daniel Jacobowitz
Reply to: