Ladavac Marino once wrote:
> [ML] Sadly, in the memory overcommit situation, there is no way to
> know whether a pointer returned by malloc will cause a process demise
> or not. The pointer is valid, but the swap area mapping is defered
> until the page is dirtied (basically, the pointer points to a readonly
> zero filled physical page and on write the trap handler tries to
> allocate a backing swap area for the page. If the swap is exhausted,
> the handler eventually fails. What the system does at this time is
> irrelevant.
[...]
> Please note that memory overcommit architectures are a rather common
> optimization; FreeBSD is one of them. They do, however, break the
> ISO/ANSI C conformance (strictly speaking).
Aha, now its clearer. May be, since we are do not conform anyway,
we can design some clever way of notifying a program rather then
SIGKILL-ing it?
Perhaps, SIGBUS? Something, a program can catch, if it is prepared
to, and, may be, do some syscall to find out which chunk of memory
can not actually be used by it...
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
