Mac Mini running Yosemite randomly shutdowns then gets caught in reboot cycle for a while - logs don't show much

Question

Running a Mac Mini 2.5 GHz Intel Core i5 with 16GB RAM. I've recently been experiencing random shutdowns that appear to have no noticeable cause in the logs. This is a log showing the most recent slot of time where a shutdown occurred:

Nov 29 13:31:34 minimac.local screensharingd[3148]: Authentication: FAILED :: User Name: N/A :: Viewer Address: 70.33.238.149 :: Type: VNC DES
Nov 29 13:31:36 minimac kernel[0]: Google Chrome He (map: 0xffffff8047df2960) triggered DYLD shared region unnest for map: 0xffffff8047df2960, region 0x7fff90000000->0x7fff90200000. While not abnormal for debuggers, this increases system memory footprint until the target exits.
Nov 29 13:31:50 minimac.local screensharingd[3148]: Authentication: FAILED :: User Name: N/A :: Viewer Address: 69.58.96.42 :: Type: VNC DES
Nov 29 13:33:06 minimac com.apple.xpc.launchd[1] (com.apple.screensharing[3232]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.screensharing.server
Nov 29 13:33:09 minimac.local screensharingd[3232]: Authentication: FAILED :: User Name: N/A :: Viewer Address: 106.240.241.58 :: Type: VNC DES
Nov 29 13:33:20 minimac.local screensharingd[3232]: Authentication: FAILED :: User Name: N/A :: Viewer Address: 50.121.137.174 :: Type: VNC DES
Nov 29 13:33:29 minimac.local screensharingd[3232]: Authentication: FAILED :: User Name: N/A :: Viewer Address: 75.109.245.13 :: Type: VNC DES
Nov 29 13:33:39 minimac.local screensharingd[3232]: Authentication: FAILED :: User Name: N/A :: Viewer Address: 66.192.171.130 :: Type: VNC DES
Nov 29 13:33:45 minimac.local screensharingd[3232]: Authentication: FAILED :: User Name: N/A :: Viewer Address: 67.214.107.178 :: Type: VNC DES
Nov 29 13:34:37 minimac.local discoveryd[53]: Basic DNSResolver  dropping message because it doesn't match the one sent Port:53 MsgID:39067
Nov 29 15:46:18 localhost bootlog[0]: BOOT_TIME 1417304778 0
Nov 29 15:46:39 localhost syslogd[16]: Configuration Notice:
    ASL Module "com.apple.AccountPolicyHelper" claims selected messages.
    Those messages may not appear in standard system log files or in the ASL database.

I've since closed off VNC though I don't see how that would have been a cause. I don't have any power monitoring in place, but I'm working on that avenue also. Is there some kind of additional verbose logging I could setup to better understand what is triggering the shutdowns?

Also, after these random shutdowns, the machine will reboot several times after the password screen before finally returning to a stable state.

So I guess for the purposes of an accurate question:

1. Does anyone see anything in those log lines that are suspicious?
2. Is there additional logging I can trigger for more detail?
3. Does anyone know of this problem elsewhere?

Update:

• Apple Hardware Test came back clean
• I had two 3rd party apps that ran in kernel space: Little Snitch and Macproxy
• Removing Little Snitch didn't help - the random reboot happened
• However, removing Macproxy has resulted in no reboots for some time now.

I'll leave the system running in the current configuration and report back what I find.

Thanks for the pointers!

Update 2: I followed that message

Nov 29 13:31:36 minimac kernel[0]: Google Chrome He (map: 0xffffff8047df2960) triggered DYLD shared region unnest for map: 0xffffff8047df2960, region 0x7fff90000000->0x7fff90200000. While not abnormal for debuggers, this increases system memory footprint until the target exits.

And after trying out a bunch of stuff (SMC reset, PRAM reset, etc) I discovered that closing Chrome alleviates the sudden reboot. I've got several hours of uptime now with Chrome closed. To finalize my hypothesis, I'll restart it and see if it crashes again. I see some anecdotal references via Google to Chrome crashing Macs, but nothing was a smoking gun.

Answer 1

The message:

triggered DYLD shared region unnest for map

says that the application memory footprint expand (as the warning indicates) and it consistently ranks among the top "Significant Energy Use" apps.

In other words, these DYLD errors are reported by kernel which indicates abnormal eating of memory.

From technical point of view, this happens when the application need to make a text page writable to overwrite the prologue with a trampoline and DYLD needs to update its page mappings as a result of this protection change. In Chrome this is caused by using mach_override() for the CFBundleBlocker (chrome::common::mac::EnableCFBundleBlocker).

So this is what the kernel is logging about, and it seems harmless given that this is an intentional protection change being issued.

In osx/10.9.5/xnu-2422.115.4/bsd/vm/vm_unix.c in log_unntest_badness() there's a system-wide sysctl (set("vm.shared_region_unnest_logging")) that can disable this logging.

So you can disable this, run:

sudo sysctl -w vm.shared_region_unnest_logging=0

In order to make this vm.shared_region_unnest_logging=0 permanent, you need to add to /etc/sysctl.conf.

Or if your application crashes (see: Bug #136801), you may try to fix it by the command:

sudo update_dyld_shared_cache -force

See: Fix for applications (TextWrangler, Chrome, Evernote, iPhoto …) crashing on startup in Mountain Lion

So you may experience some freezes and this could be the result due to some other uninterruptible processes (e.g. due to some I/O errors).

Sources:

• Chrome Issue 428858: Lots of "triggered DYLD shared region unnest for map" log messages
• Firefox Bug 804010 - firefox/thunderbird triggered DYLD shared region unnest for map

Answer 2

Sounds like there could potentially be a hardware issue. Have you tried running the Apple Hardware Test/Diagnostics?

You can also attempt to run safe mode, which includes an automatic disk check and repair utility.

My reasoning is that it sounded like a RAM issue if you are having random restarts and restart loops. I would especially say so if you started getting errors. I'd say run a hardware test in order to see if there were any issues with the RAM.

I reason that it isn't overheating issues, as those tend to just be random shutdowns and instability. I decided to add the safe mode/disc check just in case. I highly doubt it would be anything hard disc related, such as corruption, seeing as you're eventually able to log in to the OS.

This is just from my experience with PC hardware, which isn't that far off from Mac hardware. Mac software, however, I am not that knowledgeable on.