Re: what is expected malloc behavior re. limits/insufficient resources?
Re: what is expected malloc behavior re. limits/insufficient resources?
- Subject: Re: what is expected malloc behavior re. limits/insufficient resources?
- From: Terry Lambert <email@hidden>
- Date: Wed, 24 Dec 2008 14:47:55 -0800
On Dec 24, 2008, at 6:37 AM, IainS <email@hidden>
wrote:
Hi,
On 10.{8,9}
You probaly meant an earlier version; if not, what year is it and are
there flying cars yet? 8)
In a situation where the malloc request:
is < MALLOC_ABSOLUTE_MAX_SIZE
but > [total RAM + total free swap partition space]
or > ulimit -v , or ulimit -d (regardless of soft/hard)
it seems that malloc() returns a non-NULL pointer (i.e. without
error).
It returns a pointer into a page mapping in the process virtual
address space. No physical pages are allocated until you touch them.
This can exceed total RAM plus swap because of memory overcommit,
which has pretty much been SOP on unix since the DEC VAX version
introduced virtual memory.
Subsequent use of the returned pointer can (and does) bring the
system down
Define "down".
once you see a "no free paging space left" message thing are looking
grim.
Yes the system will spend most of its time attempting to clean pages
for you to satisfy your applications demands.
Interposing malloc debug puts up the appropriate "insane request"
message - but under 'normal' malloc the program runs on happily
until the system dies.
----
(a) Is malloc() supposed to honor ulimits?
(b) Is malloc() supposed to allow requests in excess of available
system resources?
( I would be amongst the first to agree that providing a robust
solution is non-trivial -- but... that doesn't mean it isn't worth
trying).
- There doesn't appear to be a RLIMIT_VMEM so that control is not
avail.
----
This behavior is troublesome - because a simple non-privileged
program compiled -m64 can easily stop the system
(with loss of any data that depends on a program that depend on
malloc --- i.e. pretty much all of them)
does any of the behavior described constitute a bug -- or perhaps an
enhancement ?
cheers and season's greetings,
Iain
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden