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.

Instapaper developer Marco Arment responded to the latest installment of John Siracusa’s famously elaborate Mac OS X reviews with an amusing, fairly elaborate review of the review itself. Each is worth reading, or at a minimum, each is worth reading later.

Siracusa’s article is particularly suitable to archiving for later perusal, as it clocks in at a whopping 24 “web pages.” Arment estimated it took him around two hours to read. Given my busy schedule and poor attention span, I suspect this will be split up into several shifts, reading a little bit when I get the chance.

Multi-page articles used to be a bugaboo for Instapaper. Faced with an article like Siracusa’s, it would happily save it to your reading list, but when you sat down to dig into the story, you’d be vexed to find you were stuck with only the first of 24 pages. Happily, in March of this year, the Instapaper bookmarklet was updated to support multi-page archival.

I have an Instapaper keyboard shortcut wired up, so when I’m looking at a page I want to read later, I just press control-p, and up comes Instapaper’s friendly “Saving” panel. When it’s saving a multi-page article, it updates the UI while it cranks through the pages.

I pressed the keyboard shortcut on Siracusa’s article, and settled in for a relatively long Instapapering lull. To my surprise, the save panel appeared and disappeared almost instantly. Uh oh, has Marco screwed up multi-page archiving for a canonical example of its usefulness? On an article that he himself has drawn additional attention to?

Nope. All the pages are there. I confirmed through Instapapaper that the complete, gloriously long article would be waiting for me on my subway ride later this morning. Kudos to Instapaper!

But how did it happen so quickly? Does Marco special-case certain popular pages like this in an effort to boost perceived performance? Or perhaps one of the subtle improvements over the years has been some kind of automatic server-side de-duping of archives. This would save Marco a bunch of space on his servers while also improving performance for users.

Archiving Advice

However Instapaper did it, archiving John Siracusa’s review of Mountain Lion 10.8 with Instapaper was, ahem, instant and complete. Would archive again.

Now that Safari 6 is available as part of Mountain Lion 10.8, and as a software update for Lion, I can finally explain the rumblings I made months ago about an extension facilitating feed subscription directly from Safari.

The motivation behind my foray into Safari extension development was my early adoption of Safari 6 during the beta phase. I noticed they had removed the long-standing, built-in “RSS” button near the URL bar. This button makes it easy to subscribe to an RSS or Atom feed for a blog, or any other site that offers such a feed.

I’m disappointed by Apple’s decision to remove the button, but when life hands you lemons …

My beta-quality, more-or-less unsupported Subscribe to Feed extension adds a handy button to the toolbar that, when a page offers RSS or Atom feeds, can be clicked to easily open the feed:// link, which should automatically open your favorite news reader.

I hope this extension fills a void for those of you missing the beloved RSS button from Safari 5 and earlier.

Updates:

• Since I posted this on Wednesday (the day Mountain Lion 10.8 was released), the response has been overwhelming. I didn’t realize there would be so much interest in restoring the functionality of the Safari RSS button.

  The interest has been so strong that more than a couple people have installed the extension apparently unaware of its purpose. The gist of the extension is to make it easy to subscribe to RSS and Atom feeds in an external application, separate from Safari. For example, it will open in NetNewsWire, Reeder or any other application on your Mac that claims to support “feed:” style URLs.

  Some folks who are just getting in to desktop RSS readers are discovering they don’t have a “default app” setting on their Mac, and Apple no longer provides a simple UI inside Safari for setting the default. The best solution I know for this issue is to download and use the venerable RCDefaultApp to set a default RSS reader for your Mac.

• A number of users who use Google Reader through the browser would like it if there were a way for this extension to automatically subscribe in Google Reader instead of through a Mac client. I’m not sure exactly how this would work but I bet it’s possible with a preference in the extension that would offer the ability to open a Google Reader URL for subscribing. This is a little ambitious though, so if you want this feature and happen to be able to code Safari/JavaScript solutions, please send me a proof of concept for subscribing to Google Reader from JavaScript on a web page, and I’ll see if I can integrate it into the extension.
• On August 2, 2012, I released Subscribe to Feed 1.0b4, addressing a number of issues from the initial release.

MarsEdit has featured support for connecting to Tumblr blogs since February 27th, 2009. Since that time, it has always lacked a few features such as support for editing video and audio posts, but with the exception of some particularly flakey periods in Tumblr’s network availability, the feature has been solid, and appreciated by mutual customers of Tumblr and MarsEdit.

Earlier this week Tumblr quietly, and without warning, changed the behavior of the API that MarsEdit and countless other apps rely upon, removing the ability of clients to authenticate with a user’s username and password. In particular, when asking Tumblr to provide a list of posts stored on the server, authentication fails and an error code is returned in lieu of the requested posts. The result for users of MarsEdit is a never-ending string of requests for the username and password, and posts from the blog never appear in the app.

After learning of and researching the issue, I contacted Tumblr’s engineers with a message to the Tumblr API discussion group. I was heartened to receive a reply within minutes, from John Bunting of the Tumblr team, that they were looking into the issue. A few minutes later, it was clear that they understood the cause to be a policy change within Tumblr that was made on purpose.

The policy change is, in short, that user credentials may no longer be provided as part of the URL scheme in requesting assets for the blog. For example, a request to read draft posts on a Tumblr site might look like this:

http://myblog.tumblr.com/api/read?email=joe&example.com
			&password=123badpass&state=draft

Instead, the same authentication details should be provided in the body of the POST request. The security improvement here is modest: as the connection the API is not over HTTPS, the entire content of the POST request could be intercepted as easily as the URL for the request. However, my friend Mike Ash pointed out that there is some rationale for keeping sensitive data out of request URLs as they are more likely to be logged and kept around longer-term than the content of a request.

In the previously linked Tumblr API discussion, Tumblr proposed that clients such as MarsEdit should switch to providing authentication information in the body of the request, but offered that perhaps they could temporarily restore the “old behavior,” for perhaps two weeks, while developers update client apps to meet the new requirement.

First, two weeks is not a lot of time to adapt to a sudden change like this. Anybody who develops for the Mac or iOS App Stores knows that sometimes an app can sit in review for two weeks before it’s even considered for approval. Still, a grace period would be better than leaving all of my Tumblr-blogging customers in the lurch, so I immediately set out to adapt MarsEdit to work with the new requirements.

Here’s the rub: the new requirements don’t work, either. For the API call in question, the “/read” endpoint, none of the arguments, username and password included, are recognized by Tumblr from the body of the POST. As far as I can tell, parameters must be provided in the URL for the request, except Tumblr has now explicitly stopped respecting the username and password arguments.

In short: clients of the V1 Tumblr API are no longer able to read posts with authentication from the service. Since the early, attentive responses in the discussion group two days ago, there has been no further update. MarsEdit, and other clients of this API, are effectively broken until and unless Tumblr restores functionality of the API.

If you’re familiar with the Tumblr API, you may be wondering why I haven’t yet adopted the newer V2 API. It supports OAuth authentication which is certainly more secure than the scheme being used in V1. But when I looked into supporting it, I hit different hangups that would alter the behavior of MarsEdit and prevent me from supporting current features. For example, it appeared impossible to access “private” posts through the V2 version of the API. I wrote them about that, too, a year and a half ago, and never heard a reply.

As a developer who relies upon Tumblr’s API, there has been no shortage of frustrations over the years. Whether it be the reliability issues, the absence of certain important API calls, or sudden changes in behavior such as this. I’ll come out and say it: it’s damned frustrating to support Tumblr, and sometimes I wonder if I was a fool to ever try to do it.

If you use MarsEdit for Tumblr, you are undoubtedly frustrated by the recent collapse of support for the service. I’m frustrated, too. I’d like to say it’s all in my hands to fix things, but it isn’t that simple. I can make further concessions, removing features to adopt their V2 API. But doing that will take time, testing, and energy. With Tumblr, more energy than it should. It takes two to tango, and Tumblr doesn’t dance.

Update: A very helpful reader who has experience with the Tumblr API suggested that I should be able to adopt the OAuth authentication of the V2 API while continuing to use the V1 API (for features that aren’t supported on V2). This is a promising lead. It doesn’t diminish my frustration with Tumblr for yanking the rug out from under existing clients like this, but if it works as advertised, it does put the situation squarely back into the domain of “something I can solve on my own.”