site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com LOL .. getting my darwins and OSXs mixed. this is understood - the pointer is harmless until used.... unusable - generally to the extent that a hard reboot is required. (a) Is malloc() supposed to honor ulimits? Is there any official answer to these? Thanks, 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/site_archiver%40lists.appl... On 24 Dec 2008, at 22:47, Terry Lambert 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. I'm sure you're right --- but these platforms must have had some way of saving you --- I don't remember having this trouble ever on a VAX or a Sun (or even a Prime)... ;-) 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. AFAICT any process that tries to request memory after the system has run out of paging space is put to sleep. Effectively, unless one can kill the process that's oversubscribed the memory, the system is deadlocked (since, these days pretty much every program relies on malloc) Even something simple like the display sleeping is enough to require a hard-reboot - since one cannot ssh (no new process can be started)... etc. etc. (b) Is malloc() supposed to allow requests in excess of available system resources? This behavior is troublesome - because a simple non-privileged program compiled -m64 can easily stop the system non-privileged programs ought not to be able to make the system unusable (IMO). (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 ? If it cannot be regarded as a bug, perhaps honoring ulimits or providing RLIMIT_VMEM would be a very useful enhancement? This email sent to site_archiver@lists.apple.com