site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi, 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) Define "down". ---- (a) Is malloc() supposed to honor ulimits? ---- cheers and season's greetings, Iain _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Dec 24, 2008, at 6:37 AM, IainS <developer@sandoe-acoustics.co.uk> wrote: On 10.{8,9} You probaly meant an earlier version; if not, what year is it and are there flying cars yet? 8) 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 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. (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 ? This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com