Before Mountain Lion 10.8 shipped, I had received reports from one customer that MarsEdit was crashing each and every time he attempted to access the network. For an app like MarsEdit whose entire raison d’être is to access the network, this is quite an unfortunate obstacle.

The public release of Mountain Lion has only confirmed that the problem, while rare, is significantly wide spread that I’m sure it affects at least dozens of my customers, hundreds of the customers of my colleagues, and probably thousands of Mac users worldwide.

The tell-tale sign of this crash is it occurs only as the app attempts to connect to some network resource, and the crashing thread always culminates in some stack trace involving CoreSchedulingSet or EmptyCoreSchedulingSet C++ objects.

Here’s one example, with just the crashing thread a few stack frames deep:

Thread 1 Crashed:: Dispatch queue: com.apple.root.default-priority
0  com.apple.CFNetwork              0x00007fff8d26cc92 CoreSchedulingSet::
			copyWithUpdatesReleaseSelf(CoreSchedulingSet
			const*, CoreSchedulingSet const*) const + 104
1  com.apple.CFNetwork              0x00007fff8d26c995
			CoreSchedulingSet::copyWithAdditionReleaseSelf(__CFRunLoop*,
				__CFString const*) const + 71
2  com.apple.CFNetwork              0x00007fff8d2cfac6
			__executionContextSchedule_block_invoke_0 + 44

And another, where the non-main thread crashes in an EmptyCoreSchedulingSet destructor:

Thread 3 Crashed:: Dispatch queue: com.apple.root.default-priority
0  libsystem_kernel.dylib            0x00007fff8d089212 __pthread_kill + 10
1  libsystem_c.dylib                0x00007fff913b2b34 pthread_kill + 90
2  libsystem_c.dylib                0x00007fff913f6dfa abort + 143
3  com.apple.CFNetwork              0x00007fff8fd8c928
			EmptyCoreSchedulingSet::~EmptyCoreSchedulingSet() + 60

Google searches, and some chat I’ve seen on Twitter, suggests the problem is certainly not limited to MarsEdit. Even Safari is vulnerable to these crashes in the affected configurations.

So what are the affected configurations? I’m not sure. Anecdotally, it seems like you’re more likely to see the problem if you are connecting in an institutional network such as a school or a large company. One customer also mentioned that he crashes when connecting through the Thunderbolt ethernet adaptor, but is able to connect without issue through the WiFi interface for his Mac.

I am posting this here in an attempt to document the known symptoms and scenarios for this crash, in case it helps other developers and customers who run into the issue.

I hope that Apple will issue a fix for this in 10.8.1, if not sooner. It sounds like this is affecting an awful lot of customers and as far as I know there is no workaround, short of changing the circumstances of how you are connecting to the internet by using a different interface or moving to a different location.

Update: I am now convinced by putting the pieces together and correlating my experiences with those of folks including the support crew at Agile Bits, that this is issue is related specifically to the “Auto Proxy Discovery” and “Automatic Proxy Configuration” settings in Network preferences. If you have one of these options checked, you are very likely to crash in MarsEdit, Safari, Tweetbot, and any number of other apps that rely on Apple’s networking libraries.

I recommend turning off the Auto Proxy Discovery and Automatic Proxy Configuration features in 10.8 unless you are on a network where using them is strictly required.

Click here for detailed instructions.

In light of the apparent link to a commonly used proxy configuration, and the growing number of apps confirmed as affected by this issue, I am hopeful that we’ll see a fix from Apple sooner than later.

This entry was posted to Apple, Mountain Lion. Comments are closed. Thanks for reading!