Mac OS X Mavericks freezes, stops responding when running out of memory

Question

It happens every other day and the symptoms are weird to say the least. The computer still responds in some sense; I can move the mouse, the volume buttons on my headphones work. They keyboard does nothing though, neither does clicking. No hover states are presented. It is as if the mouse pointer isn't really moved.

I can use the computer if I log in from another computer using SSH or using a remote from my phone (I use Rowmote.) It is very slow, though - but it responds.

In this state, I can do very few things. Starting new applications is a roulette, for example I could start Activity Monitor (nothing odd to be seen) but starting Console after that was not possible. Closing apps gave odd results until finally it stopped responding to the remote as well. Interestingly, the remote application didn't think it had lost the connection so somehow it still received and acknowledged the remote commands.

Here is the relevant /var/log/system.log output from the moment it happened:

Jan  3 10:39:19 knifen.local WindowServer[119]: CGXCreateShmem : mach_make_memory_entry(268453900: unknown error code) : Cannot map memory
Jan  3 10:39:19 knifen.local WindowServer[119]: _CGXCreateWindowInline: Creation failure 1007
Jan  3 10:39:19 knifen.local Dock[15204]: CGSNewWindowWithOpaqueShape: Cannot create window
Jan  3 10:39:19 knifen.local WindowServer[119]: CGXCreateShmem : mach_make_memory_entry(268453900: unknown error code) : Cannot map memory
Jan  3 10:39:19 knifen.local WindowServer[119]: _CGXCreateWindowInline: Creation failure 1007
Jan  3 10:39:19 knifen.local Dock[15204]: CGSNewWindowWithOpaqueShape: Cannot create window
Jan  3 10:39:28 knifen.local WindowServer[119]: BUG in libdispatch: 13A603 - 2930 - 0x1000480c
Jan  3 10:39:51 knifen kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Jan  3 10:40:50 knifen.local Spotify[13941]: Got disconnected: Error Domain=GCDAsyncSocketErrorDomain Code=4 "Read operation timed out" UserInfo=0xfa075f0 {NSLocalizedDescription=Read operation timed out}
Jan  3 10:40:55 knifen kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Jan  3 10:41:50 knifen.local hidd[95]: IOHIDEventQueue unable to get policy for event of type 11. (e00002e8)
Jan  3 10:41:56 --- last message repeated 113 times ---

I am not really wondering anything here, if you have tips I guess that would be good. It seems to be bad engineering on Apple's part.

Answer 1

When the OS is starved for room on disk, bad things happen by design in an effort to try to keep the critical parts of the system online long enough to let a controlled crash happen and potentially let apps with changes to save survive until the cleanup activity starts.

Mavericks is much less likely to allocate the full amount of RAM to /var/db/sleepimage so people used to having that space preallocated can run into surprises when the OS needs a little room to grow the sleep image if operating conditions dictate.

The main tip would be to preserve several gigabytes of free space on the bootable volume when you have a workload that stresses the virtual memory system and runs with memory pressure in the red.

Here are my recommendations:

• What scale or measure does Mavericks' and Yosemite's "memory pressure" adhere to? has some good information on monitoring and causing memory pressure on command
• boot your system, log in one user, quit all applications
• open activity monitor and observe / record the memory screen
• put the machine to sleep and wake it 30 seconds later
• run sudo du -sm /var/vm/* and note how large your sleep image file is as well as whether any swap files have been created on disk.

You will want to have ideally enough space on disk free to match your total memory footprint if you intend to run programs that take the virtual memory system into yellow territory for memory pressure. You probably won't need all that space for just the OS, but especially if you are getting mach memory errors like you are listing, the workload you are running needs a little more free space to grow than you are allowing.

Additionally, if you feel the system tuning is incorrect, you could easily file a bug report by running sysdiagnose after a clean boot as described above, once again when the system is running the intended workload properly and one last sydiagnose run once you've caused the memory allocations to start breaking the system. It's possible there are better choices Apple could have made, but it also could just be your software is buggy / leaking memory and the system is breaking as it was intended when the finite resources it has have become exhausted. Without more details it's hard to tell which is the case.

Answer 2

"shmem" is shared memory, and OS X is failing to allocate shared memory. It therefore seems the computer has run out of memory, both RAM and hard drive memory. Is this the case? At the time of freeze, there seemed to be about 1GB of space left.

• Free up disk space by deleting files
• Free up memory by closing applications

In this particular case, the logs later indicated that Spotlight had been trying to index a mounted sparsebundle volume, resulting in the backing disk running out of space.