It's probably waiting for the VM to free up some space, which the VM
then fails to do.
I unfortunately have first-hand experience of running a Mac completely out of disk space [and hence, swap] — it it does suspend processes as they request more vm space. There’s also an alert that pops up onscreen, and also the Force-Quit panel appears, showing which apps are suspended.
Michael, if you didn’t get onscreen alerts about the system running out of disk space, this probably isn’t what happened. (Also, the backtrace doesn’t look like what I’d expect. I would think that in this situation malloc would be calling vm_allocate to grab more address space.)
On May 10, 2017, at 8:34 AM, Michael Domino < email@hidden> wrote:
I think it might be related to a low memory condition. But, the question is, why doesn’t malloc just return null?
I am not an OS guru, but my understanding is that on most desktop OS’s malloc _never_ actually returns null. The amount of address space is effectively unlimited, so malloc can just keep handing out more forever, as long as there’s disk space to back it up. But you don't want a rogue process to eat up the whole disk (and effectively freeze the whole computer with VM thrash), so the OS will periodically kill processes using more than some limit of memory. On Linux this is called the “OOM killer”; I’m not sure if macOS has a direct equivalent.
There’s also the issue of overcommit: some kernels will give a process address space without mapping all of it to backing store. Instead the backing store is allocated as pages are written to. But if the disk runs out of space, the kernel might fail to acquire backing store for a page, and have to kill the process instead. The user-space view of this is that your malloc call succeeds, but at some point when you write into the malloced memory you crash.
(There are some interesting parallels to banking and currency systems, with money as address space and gold as disk…)
—Jens |